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I. INTRODUCTION 


The direction of both the Navy and Department of Defense has changed over the 
past few years, with an increased emphasis on expeditionary warfare and _ littoral 
operations [1,2,3]. Air-to-ground and ship-to-shore communications are a necessity for 
littoral operations. A conceptual network which could provide the necessary 
communications backbone for littoral operations is proposed as portrayed in Figure 1 [4]. 
The conceived network supports this requirement with a series of routers interconnecting 
the sea-based forces, aerial elements, and the mobile warfighters ashore. 

In an effort to determine the feasibility of this network, this thesis develops a 
model and simulation of the communications link between the ground based warfighter 


and an interconnecting router. The link is modeled as a single cell within the network. 


line Counter 


ee 





Figure 1. Proposed Expeditionary Warfare Communications Network [from [4]] 


A. OBJECTIVES 


The objective of this thesis is to develop an OPNET model and simulation of the 
communications uplink for the proposed system shown in Figure 1. The modeling tool 
used is MIL 3 Inc.’s Optimized Network Engineering Tool (OPNET), version 3.0.A. This 
effort concentrates on the medium access control (MAC) layer and the physical layer. 
The model incorporates data and voice traffic sources. Medium access control is 
implemented with the slotted ALOHA protocol. The physical layer is implemented as a 
spread spectrum code division multiple access (CDMA) system. The system is simulated 


in OPNET and the bit error rate and channel utilization performance results are presented. 


B. ORGANIZATION 


This thesis is organized as follows. Chapter II provides the theoretical background 
for the model. Chapter III addresses the implementation of the transmitter. The system 
traffic models are reviewed, and the details of the slotted ALOHA MAC and direct 
sequence spread spectrum implementation are covered. Chapter IV covers the 
characterization of the RF channel using OPNET’s pipeline stages. Chapter V outlines 
the implementation of the receiver and gives the specifics of multiple access reception. 
Chapter VI presents the simulation results and evaluates the system performance. Chapter 
VII concludes this effort and offers recommendations for future development. 

Appendix A gives an overview of the OPNET modeling software for the reader 
who is unfamiliar with the package. Appendix B details the specifics of the OPNET 
pipeline stages. The details of the Interference, SNR, Bit Error Rate (BER), and the Error 
Allocation pipeline stages are explored. Appendices C through E provide the OPNET 
model source code for implementing the transmitter, the pipeline stages, and the receiver, 


respectively. 


Il. BACKGROUND 


This thesis concerns the modeling and implementation of the cellular environment 
depicted in Figure 2.1 The system 1s considered a single cell with K nodes. The nodes are 
assumed static within a cell radius of five kilometers. Power control is implied in that 
each node is equidistant from the receiver and all transmit equal power. The model 
includes voice and data traffic generation and focuses on three distinct areas: medium 
access control, spread spectrum code division multiple access (CDMA), and the radio 
channel. Figure 2.2 depicts the link between a single node and the receiver. This thesis 
models each functional block, and this chapter presents the theoretical basis for each 
block. 
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Figure 2.1. Cellular System Overview: 
Base Station Encircled by K Nodes 
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Figure 2.2. Single Communications Link between Node and Receiver 


A. TRAFFIC MODELING 


The traffic considered for this system 1s a combination of voice and data packets 
generated from a user application layer. Considerable effort has been devoted to modeling 
both voice and data traffic [5]. Here we utilize the traffic models developed by Uziel [6]. 

Uziel proposes low rate models for voice, video and data. The low rate models are 
especially applicable in this environment because of the limited channel rate. The voice 
model is based on Brady’s [7] Markovian model for a two-way conversation. The model 
in [6] is represented as a three state birth-death Markov process. It generates voice traffic 
at a mean rate of 75 packets/sec. 

The data model [6] is represented as a hybrid three state Markov chain consisting 
of inactivity, low activity, and high activity states. The low activity state considers transfer 
of text files, email messages and such, and this activity is expected to occur frequently. 
The high activity state considers much larger data transfers such as imagery and graphics 
but is expected to occur much less frequently. Though both low and high active states 
offer the same data rates, the /ow activity state produces an average of 50 packets/burst 
while the high activity state produces an average of 1,000 packets/burst. Consequently, 


the model generates data traffic at an average rate of 3.85 packets/sec [6]. 
B. MEDIUM ACCESS CONTROL 


In this section we analyze the theoretical performance of slotted ALOHA medium 
access control. The performance of access contention techniques can be evaluated by the 
measuring the system throughput, which is defined as the average number of successful 
receptions per unit of time. Assuming packet transmissions have a Poisson distribution, 


the system throughput is defined as R = At, where A is the mean arrival rate and Tt is the 


packet duration in seconds. The normalized throughput T is defined as the total offered 


load to the system times the probability of a successful transmission: [8] 


T = Rx Pr{nocollisions]= At x Pr[no collisions]. 


The probability that 7 packets are generated by the user population during a given packet 


duration interval, assuming a Poisson distribution, is given as 


Re’ 


ni 





Prn|= (2.1) 


The probability that zero packets are generated, thus there are no collisions, during this 


time interval is given by 
a= een 22) 
The time interval in which packets are susceptible to collisions from other packets 


is referred to as the vulnerable period, V, [8]. Figure 2.3 depicts the arrival of packets and 


the vulnerable period V, = 2t where packet collision is possible. 
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Figure 2.3. Vulnerable period of packet collision [from [8]] 


I Slotted ALOHA 


Slotted ALOHA divides the time axis into slots of length greater than or equal to 
the packet duration t. All transmitters are synchronized and allowed transmissions only at 
the beginning of a slot. Although multiple packets may arrive during any slot, 
transmitters will only transmit one packet at the beginning of each slot. This 
implementation prevents partial collisions as a packet experiences either total collisions 
(all packets are the same length) or no collision. [9] 

The vulnerable period for slotted ALOHA is t or one packet duration. The 

R 


probability that no other packets will be generated during the vulnerable period is e™“*. 
Normalized throughput for slotted ALOHA is obtained as [8,9] 


err (2.3) 


The maximum throughput 1s found by taking the derivative of Equation (2.3), and 
solving for R: 


dT 
—(T =Re* J=e"* —-Re’ =0 2.4 
ma (2.4) 


which yields R,,,. = 1. The maximum throughput of the slotted ALOHA system can be 
found by substituting R,,, = 1 into Equation (2.3): 


T =e | =0.3679. 


C. SPREAD SPECTRUM 


In this section we review the spread spectrum concepts of code division multiple 
access (CDMA) techniques. Direct sequence (DS) and frequency hopping are two 
common techniques. Here we consider DS CDMA only. For a detailed study of spread 


spectrum techniques, the reader is referred to [10]. 


A Direct Sequence Spread Spectrum 


Implementing DS spread spectrum requires the generation of a pseudo-random 
signal (PN sequence) resembling a binary wave form, followed by the spreading of the 


information signal with the generated sequence. 
a. Generating the PN Sequence 


PN sequences (codes) are typically generated using sequential logic 
circuits consisting of a shift register of n stages (degree n) and a feedback loop. We focus 
on linear feedback shift-registers as depicted in Figure 2.4. The shift register is initialized 
with an initial binary load. With each clock pulse, the binary sequences are shifted 
through the register, and the output of selected stages of the register are tapped and fed 
back to the feedback logic. The feedback logic consists of an exclusive-OR gate, whose 


output becomes the input to the register. 


p> - Output sequence 
Clock 


Figure 2.4. Five Stage Linear Feedback Shift Register for Generating PN Sequences 


If the initial condition (IC) of the shift register in Figure 2.4 is set with a binary 
sequence that causes the register to cycle through all possible (2”) states, the PN 
sequence generated is known as a maximal length sequence (ML) or m-sequence. The all 
zeros State is not allowed. Thus, an m-sequence shift register produces 2” — / states. 

The feedback taps of the shift register can be described as the characteristic 
polynomial. The polynomial characterizing the feedback in Figure 2.4 is 1 + D’ + D”. 


This characteristic polynomial can be denoted R(xj), i = /,2,..,n, where x; indicates the 
feedback stages. For example, R(3,5) fully describes the register of Figure 2.4. [10,11]. 
Not all polynomials produce m-sequences. Those that do are known as primitive 


polynomials. The number of primitive polynomials of degree 7 is found from [10] 


2 
N.= —— 2 





where J is the number of prime factors and p; are the prime factors of 2/ — J. As an 


example, consider the shift register of Figure 2.4. The only prime factor of 2° — 1 is 31. 
Thus, i =J=/, p, =31, and LY = 6. 


b. Spreading the Signal 


Spreading the information signal is accomplished by the multiplication of 
the information signal with the PN sequence as depicted in Figure 2.5. The message 
sequence and the PN sequence must be transformed from normal binary sequences to 
sequences of +1s and —ls. The resultant signal is modulated with a carrier and becomes 


the actual transmitted signal. 
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Figure 2.5. Simplified DS-SS Transmitter [from [8]] 


Figure 2.6 depicts an information signal waveform and the corresponding PN 
sequence waveform generated using the configuration of Figure 2.4 with an initial load of 
00101. The PN sequence is multiplied with the information signal. The resulting signal is 
equivalent to the PN sequence for all data bit 1s and the inverse of the PN sequence for 


all data bit Os. 7, is the time duration of the data bit pulse, and 7. is the time duration of 


the PN code pulse, often referred to as chip duration. 
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Figure 2.6. Information and PN Sequence Waveform 


As seen in Figure 2.6, this implementation produces 31 chips per information bit. 
The information bit rate R, = //T, and the chip rate R, = //T.. Defining k =2” —-1, the 


number of chips per bit, we have 


T, =k. (2.6) 
or equivalently 


R, =kR,. (2.7) 


The information data bits are spread with the complete PN sequence, such that the 
PN sequence repeats completely every bit interval. Such an implementation is referred to 
as one based on short codes. Spreading of the information bits results in what is termed as 
the processing gain of the system and can be shown as [Sklar] 


Gp; =—* (2.8) 


where B,, is the spread spectrum bandwidth and B is the minimum bandwidth of the 


data, normally taken to be the data rate R, [10,12]. For short codes, processing gain can 


be equivalently expressed as [11] 


Gs (dB) = 10log,,(k). (2.9) 


CG Despreading the Signal 


The receiver’s objective is to recover the spreaded information in the 
received signal into its original form. In addition to the desired signal, the received signal 
consists of possible jamming interference and noise [10]. Figure 2.7 offers a functional 
block diagram of a Direct Sequence Spread Spectrum receiver. Assuming 
synchronization at the receiver, the received signal is multiplied by a locally generated 


replica of the PN sequence and demodulated with the local carrier. The resulting signal is 
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Figure 2.7. Simplified DS-SS Receiver: AK = 1 User [from [8]] 








integrated over a one-bit duration 7, followed by a decision block. The receiver repeats 
this multiplication of the received signal with each known PN sequence. Thus, it can 
differentiate N, different signals. The resulting receiver can be envisioned as a bank of 


correlators. Figure 2.8 depicts NV, crosscorrelations of the received signal. 





Received 


Recovered 
Signal 


Signal 


PNnp ts 


Figure 2.8. Simplified DS-SS Receiver: Bank of Correlators [from [8]] 


D. MODELING THE CHANNEL 


Multiple paths, signal fading, shadowing, reflections, and propagation loss are 
unique concerns in the radio environment [8,13]. Path losses in radio channels have been 
studied extensively and several models are proposed in the literature [8]. This thesis 


implements the 2-ray model as defined in [8]. The defined received power is 


h?h? 
Pee (2.10) 


Tienes (ee el Te A 
d 





where P is the transmitted power, G, and G, are the respective transmitter and receiver 
antenna gains, h, is the transmitter antenna height, A, is the receiver antenna height, and 
d is the separating distance (meters) of the transmitter-receiver pair. For large values of d, 
the received power and path loss become independent of frequency in the 2-ray model 
[8]. Large distances are considered valid where d » hh, . For the system being 
considered, we have the following typical values: d= 5 km, h, < 20 meters, and h, < 2 
meters, hence the 2-ray model is considered valid for this implementation. 

The bit error rate (BER) is one of the most critical components of channel 


characterization. The BER may be a function of several parameters, depending on the 


11 


channel model used. Multipath and fading are major contributors to the radio channel bit 
error rate. The probability of error in a Rayleigh fading channel (coherent BPSK) is given 
as [14] 





| = 
P=) (ee (2.11) 
2 ey, 


where 


E(a’) is the average value of a’, the attenuation factor, and 


E 
t= SNR -10log0(Ry). (2.12) 


0 
The standard Gaussian approximation (SGA) in [15] is often used in determining 


the bit error probability in CDMA systems [8,16]. For a non-fading, noise-limited 


channel with perfect power control, the average probability of bit error is given as [8] 


(2.13) 





where K is the number of multiple users and é is the number of chips per information bit 
assuming short code implementation. 

This thesis incorporates BER modeling for both a Rayleigh slow fading channel 
and a noise limited channel without fading. The BER calculations are based on Equations 
(2.11) and (2.13), respectively. 


E. SUMMARY 


This chapter reviewed the modeled system as single cell consisting of a base 
station and K nodes. We briefly reviewed the traffic models that will be employed and 


medium access control and CDMA techniques as they pertain to this model. The 


IZ 


propagation model and BER models for channel characterization were given. The next 
three chapters detail the implementation aspects of medium access control, CDMA , and 


the radio channel using the OPNET modeling software. 


eS 





It. MODELING THE TRANSMITTER 


The goal of this and the following chapters is to detail the OPNET 
implementation of the proposed system. This chapter addresses the implementation issues 
of the transmitter. The transmitter can be divided into three functional areas: traffic 
generation, access control to the radio channel, and the physical interface of the 
transmission. Figure 3.1 offers a graphical view of the transmitter model, consisting of 
three user defined processes and the OPNET supplied radio transmitter and antenna 


modules. The objective of this chapter 1s to model each functional block. 
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Figure 3.1. Transmitter Node Model 


A. TRAFFIC GENERATION 


This section reviews the traffic models and their packet formats. Three different 
traffic models are employed. The voice and data models outlined in [6] were modified as 
necessary for this effort. A third traffic model generating a constant rate of traffic is 
added. 


Ib Upper Layer Packet Format 


As this effort is focused on the lower layers of the communications system, 
arriving packets are considered a single entity. Any required packet segmentation is 
assumed to have occurred prior to the packet’s arrival. The lower layers’ addressing and 
other responsibilities are not implemented. 

The packet format for all three traffic models is the same. Regardless of the traffic 


source, the packet generated is formatted as shown in Figure 3.2. 
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— Packet Length —— > 


Information Bits 


Figure 3.2. Upper Layer Packet Format 


2. Data and Voice Traffic 


The data traffic generation process consists of the states depicted in Figure 3.3. 
The model generates traffic at an average rate of 3.85 packets per second for each of N, 


data sources, where J, 1s user definable [6]. 
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Figure 3.3. State Transition Diagram of Data/Voice Traffic Generation 
Process[from [6]] 
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The voice model is graphically quite similar to the data model shown in Figure 
3.3, differing in that it models a two way conversation and offers a higher rate of traffic. 
Whereas the data model generates traffic for N, sources, the voice model generates 


traffic for N, two-way speech conversations at an average rate of 75 packets per second 


per conversation. 
S Constant Rate Traffic 


The constant rate traffic generator depicted in Figure 3.4 is functionally quite 
similar to OPNET’s ideal source generator. It differs in that it generates and transmits 


packets of the format shown in Figure 3.2 at a constant rate. 


(ENDSIN_INTRPT)/record_theo_load() 
Fy 





Figure 3.4. State Transition Diagram of Constant Rate Traffic Generation Process 


4. Init State 


The activity performed in the INIT state (Figures 3.3 and 3.4) is common to all 
three traffic models. Within the INIT state, the two user definable simulation parameters 


listed in Table 3.1 are queried for and obtained. The Active Sources parameter determines 
the number NV, of data or N, of voice sources the model will generate, respectively. For 


example, with N, = 10, the data model of [6] shown in Figure 3.3 will produce 10 


separate data sources, each generating an average of 3.85 packets/sec. User Data Bits is 
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the user’s choice for a data bit stream (0001110...). This bit stream is repeated over the 
length of the packet to set the bits of each packet and represents the information data bits 


received from the higher layers. 


Table 3.1. Traffic Generator Simulation Parameters 


Simulation Parameter Data Format 


Active Sources Integer 


Character String 









B. MEDIUM ACCESS CONTROL 


The reader might consider medium access control similar to access control of a 
busy freeway. Consider the RF radio channel medium as the freeway. In simplistic terms, 
this is the functionality of the MAC layer. In this section, we offer the models’ 


implementation. 
E. MAC Layer Packet Format 


We first consider the formatting of the packet performed at this level. Figure 3.5 
depicts the MAC layer packet format. A MAC header is provided, but the addressing and 
other information normally present in the header is not implemented. The MAC header 


for this model consists simply of all 1s. 


— MAC Packet Length —— 
Figure 3.5. MAC Layer Packet Format 


2. Slotted ALOHA Implementation 


In this section we discuss the INIT, IDLE, QUEUING, and TRANSMIT states of 
the slotted ALOHA process shown in Figure 3.6. The functions of this process consist of 
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enqueuing received information packets and transmitting them to the physical layer at the 
appropriate slot time. Prior to transmitting them, however, the MAC header is added to 


the information packet to create the MAC layer packet format shown in Figure 3.5. 


{ENDSIM_INTRPT)/record_slotted_stats(} 


_ —_— 





Figure 3.6. State Transition Diagram of the Slotted ALOHA Process 


a. Init State 


Within the INIT state variables are initialized and the user definable 


simulation parameters shown in Table 3.2 are queried and obtained. S/ot length allows the 


Table 3.2. Slotted ALOHA Process Simulation Parameters 


user to define a slot length of the their choice. If the user accepts the models’ default 












implementation, we determine slot length (seconds) as 


nM 


(oem (3.1) 


where L, is the packet length (bits) and X,1s the chip rate of the transmitter (bps for this 
notation; at this level, bits/chips are synonymous). Note that L, is not the MAC packet 
length in bits, rather the bit length of the packet which will be transmitted from the 
physical layer transmitter. Although this packet is not actually dealt with until the next 
section, it is important at this point to consider the spread packet that is actually 
transmitted. 

The actual packet format which will reach the physical layer was shown in Figure 
3.5. This model implements limited synchronization functionality by prefacing the MAC 
packet with a physical layer synchronization frame. A notional guard band frame is added 
as a trailer. Figure 3.7 depicts the notional physical layer packet format. Before actually 


being transmitted, this packet will be spread by the transmitter’s PN code. 


Figure 3.7. MAC View of the Physical Layer Packet Format 


This spread packet has length LZ, which the MAC process must account for in 


determining the slot length. Accounting for this spreading then, 


Lp =(Sync Bits + MAC Header + Information + Guard Band) G,, . (3.2) 


The actions performed within the INIT state are accomplished at the beginning of 
the simulation, effectively at time ¢ = 0. Upon completion, the process is forced to the 
IDLE state to await a condition invoking a transition to another state. The choices are the 
QUEUING or TRANSMIT state. 


b. Queuing and Transmit States 


Transition to the QUEUING state is invoked upon receiving a packet from 
the upper layer. In OPNET terms, the simulation kernel (SK) delivers an interrupt 
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indicating a packet arrival. Within the QUEUING state the received packet is enqueued 
and the process returns to the IDLE state. At every slot time 7, a transition is made to the 
TRANSMIT state. If the queue has packets, one is retrieved, a MAC header is added to 
create the packet format shown in Figure 3.5, and the packet is sent to the physical layer. 
The process then immediately returns to the IDLE state to await either another packet 


arrival or another slot time. 


Cc. SPREAD SPECTRUM 


I: Physical Layer Packet Format 


The task of the physical layer is to transmit the packet received from the MAC 
layer to the channel. The packet is normally prefaced with physical layer information 
consisting minimally of a synchronization frame [9]. Chapter V discusses the specifics of 
OPNET in that the SK provides implicit synchronization. Synchronization in a spread 
spectrum system is beyond the scope of the work reported here. We note its requirement 
by including nominal synchronization functionality. 

The physical layer packet format shown in Figure 3.7 has a notional guard band 


attached. The packet format without the guardband is shown in Figure 3.8. 


Sync MAC Information 
Frame Header Bits 


Figure 3.8. Physical Layer Packet Format 


The synchronization frame is defined similar to the MAC header, consisting of all 
ls. Prior to transmission, the complete packet is spread with the PN sequence assigned to 


this transmitter. 
De Spread Spectrum Implementation 


In this section we discuss the process of implementing spread spectrum. The 
process consists of the INIT, IDLE, and SPREADING states shown in Figure 3.9. 
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Figure 3.9. State Transition Diagram of the Spreader Process 


a. INIT State 


Within the INIT state variables are initialized and the user defined 
simulation parameters listed in Table 3.3 are queried and obtained. User Register Load 
defines the initial condition of the shift register used in generating the transmitter’s PN 
sequence. Polynomial is the characteristic polynomial defining the feedback taps of the 
shift register as discussed in section 2.C. Implied is the static allocation of the 


transmitter’s PN code. It is determined at initialization based on Polynomial. 


Table 3.3. Spreader Process Simulation Parameters 


Simulation Parameter Data Format ) 
User Register Load Character String 
Polynomial Character String 


Dynamic assignment or allocation of PN codes is not implemented. The PN code 














generated for the transmitter is determined within this state and maintained for 
persistence. It is used repeatedly by the TRANSMIT state for the actual spreading of the 
packet. 


b. IDLE State 


Upon completing initialization, the process is forced into the IDLE state 
where it awaits traffic from the upper MAC layer. Transition from IDLE is conditioned 
on MAC ARRIVAL, defined as receiving a packet from the MAC layer. This event 
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indicates the slotted ALOHA process has reached a slot time and has transmitted an 


enqueued packet to the physical layer for transmission. 
C. Spreading State 


This state implements the physical transmission of the MAC packets. 
After obtaining the incoming packet, synchronization bits are prefaced on the packet and 
the combined packet is spread with the PN code. 

At this point the packet consists of a sequential string of 1s and Os without 
discernible boundaries. This bitstream 1s encoded as a sequence of Is and —ls. Figure 3.8 
offers a representative view. The actual mapping 1s irrelevant; it is only necessary that the 
receiver is consistent and knowledgeable of the encoding scheme. As defined in Chapter 
II, an information bit 1 is spread with the PN sequence. An information bit 0 is spread 
with the inverse of the PN sequence. The spread Os are encoded as —1s and the spread 1s 
are encoded as +1s. 


D. THE RADIO TRANSMITTER MODULE 


OPNET provides a built-in radio transmitter module, requiring only that the user 


properly define the values for the attributes listed in Table 3.4. 


Table 3.4. Radio Transmitter Attributes 


|» ATTRIBUTE 





Name 
Channel 
Modulation BPSK, QPSK, DPSK 






RX Group Model 
TX Delay Model 
Closure Model 
Channel Match Model 
TX Antenna Gain Model 
Propagation Delay Model 


Icon Name User’s Choice 
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The values of the various Model attributes are user defined files known as pipeline 
stages. The requirements are the proper naming of the C source code file that implements 
the respective pipeline stage. The pipeline stages are the implementation of the RF 
channel, and in effect, provide the link analysis. Chapter IV is devoted to channel 
characterization and provides the details of each stage. 

Modulation is used internally by OPNET to determine the bit error rate. It is based 
on OPNET’s internally defined bit error rate tables. We will see in Chapter IV where we 
provide this model’s implementation of bit errors. Thus, this parameter is not applicable 
to this model. 

The channel attribute listed in Table 3.4 is further characterized by the parameters 


listed in Table 3.5. C; represents the respective channel of which there may be several. 


Table 3.5. Transmitter Channel Parameters 


Packet Bandwidth Minimum Spreading | Transmitted 


Format (kHz) Frequency Code Power 
(MHz) 





The data rate parameter is typically the information data rate. This parameter is 
queried in the pipeline stages and used, for instance, in the transmit delay stage to 
determine the time delay for transmitting the packets. It 1s in reality the chip rate. 

The packet format parameter defines the particular packet format utilized on this 
channel. This parameter can be all inclusive to accept packets of any format and/or 
nonformatted packets, or can selectively allow access to the channel for only defined 
formats. The bandwidth, minimum frequency, spreading code, and transmitted power are 
self explanatory user definable parameters. The spreading code parameter is of limited 
use in this model. This parameter accepts either a Boolean value or an integer. It does not 
provide the functionality needed for evaluating PN codes on a bit basis. It is disabled in 


all transmitter channels. 


EK. THE TRANSMITTER ANTENNA MODULE 


OPNET also provides the antenna module. The module permits modeling of 


directional or isotropic antennas. Interested reader may refer to the OPNET manuals [17] 


24 


for a detailed discussion on modeling directional antennas. This model employs isotropic 


transmitting antennas. 
F. SUMMARY 


This chapter detailed the implementation of the transmitter. We have followed the 
packet flow from generation through the physical spreading. The original information 
packet now has an additional MAC header and synchronization frame, and this complete 
packet has been spread with the transmitter’s PN code. The packet is now destined for a 
receiver, but it will first need to traverse the RF channel. The packet undergoes 
modifications and suffers loss in the form of bit errors as it traverses the channel. The 


next chapter details the model’s channel characterization. 


a 





IV. MODELING THE CHANNEL 


Channel characterization is a key component of any radio communications model 
and there are several critical issues to evaluate. This chapter addresses the implementation 
of these issues. Modeling radio channels within OPNET requires the 14 pipeline stages 
shown in Figure 4.1. The objective of this chapter is to model the RF channel utilizing 
these stages. This chapter presents the implementation of each stage with particular focus 
on the Interference, SNR, BER, and Error Allocation stages. 





Error Correction 







Error Allocation 





Receiver Group 











Transmission Bit Error Rate 


Delay 





Signal to Noise 
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Interference Noise 







Background Noise 






Transmitter 
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Received Power 
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Propagation Delay 





Transmitter Stages Receiver Stages 


Figure 4.1. OPNET’s Radio Channel Pipeline Stages 


A. TRANSMITTER STAGES 


1. Receiver Group 


The receiver group stage is not part of the dynamically executed stages of the 
remainder of the pipeline. It is executed only once at the beginning of the simulation. As 
radio transmissions are initiated, OPNET’s simulation kernel (SK) establishes a 
destination channel set between all known transmitters and receivers in the system. For 


each receiver the transmitter maintains a separate channel set; together all the channel sets 
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make up a destination list. During transmission (simulation), the pipeline stages will be 
executed for each channel set in this destination list. In this receiver group stage, the 
designer has the opportunity to exclude a receiver from a transmitter’s destination list. By 
default, OPNET does not exclude any receivers in the network and allows the pipeline 


stages to dynamically make the determination. We employ the default for the receiver 


group stage. 
Ze Transmission Delay 


This stage determines the time delay for transmitting the packet. The delay is 
computed as the packet bit length, L,, divided by the channel data rate, R_: 


Lp 
IX delay =o : (4.1) 


Ci 


Note that R,is the channel attribute data rate discussed in section 3.D. The delay value 


obtained is placed in the appropriate Transmission Data Attribute (TDA) of the respective 
packet. 


3. Link Closure 


The link closure stage determines if a particular receiver can be affected by a 
transmission. The functionality of this stage is similar to the receiver group stage, but it is 
executed dynamically with every packet. Link closure is determined based on the line-of- 
sight propagation path assumption between the transmitter and the receiver. By default, 
OPNET utilizes a ray-tracing line-of-sight algorithm with the earth’s surface modeled as 
a sphere [17]. The Boolean value indicating link closure is placed in the appropriate 
packet TDA. This model implements the OPNET default pipeline stage. 


4. Channel Match 


The channel match stage classifies transmitted packets as one of three categories; 
valid, noise, or ignored, with respect to a particular receiver. Ignored packets are not 
further evaluated by the remaining stages. 

Channel match 1s a function of frequency, bandwidth, data rate, spreading code, 
and modulation type of both the transmitter and receiver. These are user definable 


parameters discussed in section 3.D. Packets with non-overlapping frequencies between 
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the transmitter-receiver (tx-rx) pair are classified as ignored. Packets with one or more 
mismatched parameters are classified as noise. Packets whose set of tx-rx parameters are 
completely matched are valid. 

As the spreading code attribute is disabled in all transmitters and receivers, this 
assures no link will be classified based on the PN code within this stage. Chapter V will 


discuss how we determine a PN code match or mismatch in the receiver. 
5; Transmitter Antenna Gain 


This stage determines the gain of the transmitting antenna. The proposed system 
is modeled using isotropic transmitter and receiver antennas, which is simplistic in terms 
of necessary calculations. The uniform gain (0 dB) of the transmitting antenna is set in 


the appropriate packet TDA during the execution of this stage. 
6. Propagation Delay 


The propagation delay stage is the final pipeline stage associated with the 
transmitter. The propagation delay determines the time lapse between the transmission of 
the first bit of a packet at the transmitter and the arrival of the first bit at the receiver. As 
either transmitter or receiver may be mobile, two calculations are performed. The first 
calculation accounts for the distance separating the tx-rx pair at the beginning of packet 
transmission, and the second for the distance separating the tx-rx pair at the end of packet 
transmission. The propagation delays are calculated as 

d; 
be a (4.2) 
where dj; is the respective start/end transmission distance, and C is the velocity of radio 


wave propagation. 
B. RECEIVER STAGES 


The remaining stages are associated with the receiver. In these stages the model 
differs from OPNET’s default pipeline stages. A thorough understanding of the detailed 
workings of the OPNET software is critical to correctly model this system. Of critical 
importance are the Interference Noise, the SNR, and the BER stages. Appendix B 
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provides a detailed discussion of the model’s implementation of these three pipeline 


stages. 
i Receiver Antenna Gain 


This stage follows in concert with the transmitter. Similar to the transmitting 
antennas, the receiver antenna 1s modeled as isotropic. A uniform gain (0 dB) is set in the 


appropriate TDA. 
2. Receiver Power 


This stage determines the received power level of the incoming packet. It is 


calculated in accordance with Equation (2.9) and set in the packet’s TDA. 
3. Background Noise 


The background noise stage models noise sources other than interference noise 
sources introduced by other transmitters or other intentional interfering sources. The 


major noise contribution is due to the thermal noise power: 


N, =kT,B (Watts) (4.3) 


where k is Boltzmann’s constant, 7, = 7, + 7,, and B is the effective bandwidth of the 


receiver. Bandwidth is the user definable channel attribute (see section 3.D). The effective 


receiver temperature 7, 1s determined as 


T,=(F-)l)T, °K (4.4) 


where F is the receiver noise figure and T, is the background source temperature, taken 


to be 290 °K. The receiver noise figure is a user definable attribute. The default model 
includes a negligible contribution of ambient noise. As this ambient noise is negligible, it 
is neglected in this model. The determined noise contnbution JN, is set in the appropriate 


packet TDA. 


30 


4, Interference Noise 


This stage accounts for noise interference that packets may impose upon each 
other. In effect, it accounts for multiple access interference (MAI). This stage is invoked 
from the SK only in the case of overlapping packet reception and only at the beginning of 


packet reception. 
The interference power, NV, , on the respective packet segment is determined by 


M 
N, = DP (4.5) 
i=l 
where M is the instantaneous number of interfering packets (multiple users), and P; is the 
received power of the respective packet. In this implementation, all transmitters transmit 
equal power and are equidistant from the receiver, thus N; = MP. , where P. is given in 
Equation (2.9). 


a Signal-to-Noise Ratio 


This stage determines the SNR on a packet segment based on the background 
noise during the segment interval. The interfering and background noise are determined 
in the previous two stages. The background noise is constant over the length of the 
packet. In the case of packets of different lengths, N, may vary over the length of the 
packet with a corresponding variation in the SNR. By default, OPNET determines the 
SNR as 


ie 
SNR (dB) = 101 —___~ 4.6 
(dB) obo ay +N, (4.6) 


where P. is the received power, N, and AN, are the interference and the background 


noise, respectively. 

In the Bit Error stage, the multi-user interference is accounted for in the bit error 
calculation. The SNR pipeline stage is thus modified and the resultant SNR is only due to 
the signal to thermal noise ratio, defined as 


SNR (dB) = lo = } (4.7) 


B 
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6. Bit Error Rate 


This stage determines the packet segment BER. For packets of equal length, the 
BER is constant over the length of the packet. Otherwise, it will vary in accordance with 
the SNR. Here we implement two BER models. For modeling fading channels, the BER 
is determined by Equation (2.12). Non-fading channels are modeled by Equation (2.14). 
In this stage, we account for the interfering users whose contribution was omitted in the 
SNR stage. The calculated BER 1s set in the packet’s TDA. 


qe Error Allocation 


This stage is executed immediately after the BER pipeline stage completes 
execution. In this stage, we inject errors in the packet at the bit error rate determined by 
the BER stage. This stage determines the packet segment length defined in the BER 
stage, and sequences over this segment of the packet randomly inverting bits within the 
packet at a rate equal to the BER. As the bits are encoded as +1s and —1s, selected +1s 
are set to —1, selected —1s become +1. 

This model employs packets of equal length. Thus, the packet segment length is 
equal to the packet length, L,. The approach to injecting errors can be shown with the 


following pseudocode. 


for(i= 0; 1<L,;i++) 
{ 


random_number = rand(0,1); 
if(random_number < BER) 


invert _packet_bit(i); 


where invert_packet_bit() indicates changing the sign of the respective bit as noted in 
the previous paragraph. 


8. Error Correction 


This stage determines the acceptability of the packet. This determination is based 


upon two criteria: the availability of the receiver and the bit error rate of the packet. 


a2 


Should the receiver become disabled during packet reception, the respective packet is 
rejected and the SK automatically destroys the packet. If the rate of actual errors injected 
in the Error Allocation stage exceeds the error correcting threshold, the packet is 
rejected; again, the SK automatically destroys the packet. The error correcting threshold 


is a receiver channel attribute to be discussed in Chapter V. 
GC. SUMMARY 


This chapter encompasses the second of the three modules of this model. 
Presented was the implementation of the RF channel characterization. The first section 
reviewed the pipeline stages associated with the transmitter. The second reviewed the 
stages associated with the receiver, where we reviewed the model’s implementation of 
determining the BER and injecting the bit errors accordingly. The original information 
has thus undergone several changes: a MAC header and a synchronization frame are 
added, the bits have been spread, and errors have been injected into the packet. The final 
implementation aspect of this model is to determine if the packet is recoverable and the 


original information retrievable. Chapter V details the receiver implementation. 
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V. MODELING THE RECEIVER 


This chapter presents the receiver implementation of the model. The objectives of 
this chapter are to properly model limited synchronization, code division multiple access, 
and signal despreading in a spread spectrum system. Figure 5.1 offers a graphical view of 
the receiver model. This chapter focuses on the functions of the despreader and details the 


OPNET implementation of this spread spectrum receiver. 


radio_antenna radio_rcv PH_DESPREADER 





Figure 5.1. OPNET Receiver Node 


A. THE RECEIVER ANTENNA MODULE 


Similar to the transmitter, the receiver employs the OPNET isotropic antenna 


module. 
B. THE RADIO RECEIVER MODULE 


OPNET provides a built-in radio receiver module, requiring only that the user 
properly define the values for the attributes listed in Table 5.1. The values for the various 
Model attributes are the user defined receiver pipeline stages discussed in Chapter IV. 
The requirements are the naming of the C source code files which implements the 


respective pipeline stage. 


The value of Noise Figure is queried for in the Background Noise pipeline stage 
and is necessary to determine the receiver temperature, 7,, in Equation (4.4). ECC 


Threshold is the percentage of errors per packet that the receiver will accept; it is queried 


for in the Error Correction pipeline stage. 


cp 


Table 5.1. Receiver Module Attributes 






















User’s Choice 


The receiver Channel attribute is further characterized by the parameters listed in 
Table 5.2. These parameters are identical to those in the transmitter with the exception of 


processing gain (see section 2.C.1.b). 


Table 5.2. Receiver Channel Parameters 


Packet Bandwidth Minimum Spreading | Processing 


Format (kHz) Frequency 
(MHz) 





Cc. CONFIGURING THE RECEIVER 


This section reviews the configuration of the modeled receiver. A spread spectrum 


receiver is capable of receiving multiple packets simultaneously. To successfully receive 
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multiple packets, the receiver must first be able to synchronize with the arriving 
packet(s). This model implements limited synchronization, which we define as 
successfully decoding the synchronization frame of the arriving packets. In order to 
decode the synchronization frame, the receiver msut first despread the arriving packet’s 
synchronization frame. Despreading is accomplished by crosscorrelating the arriving 
packet’s synchronization frame with PN codes generated within the receiver. The receiver 
needs multiple PN codes with which it can attempt to despread the arriving packet. In 
configuring the receiver, we generate these multiple PN codes initially. 

The complete despreading process consists of the INIT, IDLE, SYNC and 
DECODE states shown in Figure 5.2. A detailed discussion of each state is presented 


below. 





| DECODE J 





(END_SIM)/record_final_stats(} 


Figure 5.2. State Transition Diagram of the Despreader Process 


1. INIT State 


Within the INIT state, variables are initialized and the simulation parameters 
shown in Table 5.3 are queried and obtained. Synchronization threshold and data 
threshold are thresholds which must be reached to successfully achieve synchronization 


and decode the information bits, respectively. 
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Table 5.3. Despreader Process Simulation Parameters 


The parameter /ong correlation has a significant impact on simulation 















performance. It determines the number of crosscorrelations the receiver will perform in 
the attempt to synchronize with arriving packets. As the receiver is designed to receive 
and despread < N, PN codes, these codes must be known to the receiver. For each code, 
there are k possible IC’s (see Chapter II) of the shift register and & chips per code. Thus, 
the receiver must be configured with N,k° codes which it can utilize to crosscorrelate 
with the arriving packet(s) . These codes are all generated in the INIT state and retained. 
Figure 5.3 offers a logical view of this persistent matrix of PN codes. IC, for generating 
each PN; code indicates the initial condition of the shift register was set with the least 
significant bit as 1 (Ox1), and all other bits set to 0. The remaining (up to &) codes are 
generated with the other initial conditions of the shift register. For example, the code for 


each IC, was generated with an initial condition of the shift register set to 2 (0x2). 


bit, 
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bit, 
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IC 
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Figure 5.3. Receiver PN Code Matrix 


In the SYNC state, the arriving packet is crosscorrelated with the codes of this 
matrix in an attempt to achieve synchronization. Long correlation determines if the 
model will execute < N,k* crosscorrelations as necessary, or only PN, ic, 1— |.. Nom 
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them. With Jong correlation disabled, a transmitter’s code generated with an IC other 
than Ox! should not achieve synchronization. Bit errors could prove this false. With /ong 
correlation enabled, the user has flexibility. The price is increased simulation time. By 
default, Jong correlation is disabled. The user determines the IC of the transmitter’s shift 
register with the User Register Load parameter (see Chapter III). 

Upon completion of the INIT state, the process is forced to the IDLE state, where 
it awaits incoming packets. Upon a packet’s arrival, the first objective is achieving 


synchronization. 
D. SYNC STATE 


This model implements limited synchronization functionality. As OPNET is a 
discrete time, event driven modeling system, true modeling of spread spectrum 
synchronization would be prohibitive in terms of simulation time. Slotted ALOHA 
ensures transmitted packets arrive simultaneously. Packet synchronization is achieved as 
OPNET delivers the complete packet to the receiver, 1.e., the receiver is not constantly 
sampling a received signal attempting to synchronize on a bit stream. 

A realistic modeling of this receiver would require parsing the packet bit by bit 
and correlating first one, then two, then three and on until the time we had received the 
complete packet. Synchronization is a complex issue. There is phase synchronization, 
frequency synchronization, chip synchronization, code synchronization and others to be 
concerned with [14]. As OPNET delivers the complete packet to the receiver via a stream 
interrupt, we assume that synchronization is achieved, and the treatment of 


synchronization here is limited to recovering the PN code. 
ie Determining Synchronization 


We transition to the SYNC state on the condition PKT RECEIVED, indicating 
one or more packet arrivals. From the matrix of codes generated in the INIT state, we can 
precisely outline the implementation of this state with pseudocode. The simplified 
version is as offered below. With /ong correlation disabled, j is fixed at 1, such that only 
the first sequence of each PN code will be used in the crosscorrelation process with the 


arriving packet: 
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Do{ 
for(is N,) 
for(j < k) 
sync = xcorr(PN;,, packet) 
end 
end 
S}while(sync threshold not met && more codes to check) 


Achieving synchronization of a packet is the first step in considering the packet as 
successfully received. Packets that cannot be synchronized are considered lost packets 


and they are destroyed. 
mn Multiple Access Reception 


The proposed system must incorporate multiple simultaneous reception of 
packets. The second step in deciding successful packet reception is to determine if all 
simultaneously received synchronized packets have unique PN codes. Packets containing 
duplicate PN codes are considered collisions and destroyed. 

Consider the simultaneous reception of three packets. The receiver chooses one of 
the packets. Assuming the receiver is able to synchronize on the first packet, we must 
ensure that we maintain this packet. It 1s a candidate for a successfully received packet. 
We cannot, however, consider it a valid received packet until all three have been 
synchronized and determined to have unique PN codes. If all three do contain unique PN 
codes, then, and only then, can we consider the three as successfully received packets. 

Internally, OPNET maintains an event list comprised of events scheduled for 
various simulation times. The event list contains at least three events scheduled for time 
t = now; the arrival events of the three packets. We do not transition to the DECODE 
state until we have processed all packet arrival events scheduled for time t = now. 

The model maintains each synchronized packet in a list schematically shown in 
Figure 5.4. A separate list is maintained for each defined PN code. If synchronization is 
achieved on an arriving packet, the packet is inserted in this list for persistence. Should 
two packets synchronize on PN,, both packets will be inserted into the same list. For 
example, the list pointed to by the PN, list pointer will have two packets in this list, as 
shown in the diagram. Additionally, an OPNET interrupt labeled SYNC_ACHIEVED is 


scheduled to occur at time t = now + +. After all simultaneously arriving packets have 
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been evaluated, this process returns to the IDLE state. A SYNC_ACHIEVED interrupt 
will cause a transition to the DECODE state, t seconds later. 





List 
Pointers 





Figure 5.4. Persistent List of Synchronized Packets 


3; Decoding Delay 


The parameter t referred to in the SYNC state is an induced time delay which 
prevents the process from transitioning directly from the SYNC state to the DECODE 
state. The purpose of t is twofold. First, to provide a time gap separating the events of 
SYNC and DECODE. Second, to accommodate any internal variance of times maintained 
by OPNET for the start of reception of other packets. 

The value of t must be nominal such that packets from later slot(s) are not 
included in the list of synchronized packets, 1.e., the current set of simultaneously arriving 
packets must be decoded before the next time slot. Equidistant transmitters and the MAC 
ensure simultaneous arrival. For transmitters at varying distances, we assume receiver 


feedback to ensure that all packets arrive at the beginning of a slot time. 
E. DECODE STATE 


This state determines packet collisions, despreads non-colliding packets, and 
attempts recovery of the original information. Transition to this state is conditioned on 
ACHIEVED SYNC, defined as 1) synchronization achieved and 2) invocation of a 
SYNC_ACHIEVED interrupt. 
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le Collision Decision 


Packet collision is determined by evaluating the list(s) indicated in Figure 5.4. 
Any list(s) of PN, maintaining J > 1 packets indicates duplicate codes. All J packets are 


destroyed. 
2. Strip, Despread, Decode 


For all PN, maintaining / = 1 packet, the packet is considered as received 
successfully. Now, the receiver can move ahead to decoding and despreading the packet. 
Despreading and decoding are accomplished by crosscorrelating the spread information 
bits with the respective PN code(s) recovered in the SYNC state. A single iteration 
through the list in Figure 5.4 will identify all successfully received packets which can 
now be decoded. 

Decoding results in either a recovered 1 or 0 as appropriate, or this model flags 
information bit errors as —1 for bits failing to reach correlation exceeding data threshold. 
Table 5.4 depicts the trivial case of 7 = 3, k = 7, indicating the original information bits 
were spread with a PN sequence of seven chips. Information bit 1 consists of the seven 
encoded bits shown in the first row. Information bit two follows on the second row, and 


information bit three follows on the third row. 


Table 5.4 Decision value of Recovered Data Bits 


Spread Bits, | Normalized Data 
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3. Event Canceling 










The first transition to this state results in destruction of all colliding packets and 
despreading all successfully received packets. The final actions are traversal of OPNET’s 
event list. All pending interrupt events labeled SYNC ACHIEVED scheduled for time 


= now are void, as the synchronized packet which scheduled this interrupt has been 
processed. 

For example, in the case of three simultaneous successful synchronizations, there 
were three SYNC_ ACHIEVED interrupts scheduled for time ¢ = now + 7. Time t is now 
equal to 7. One of the SYNC_ACHIEVED interrupts invoked this process. The other two 
are unnecessary. This model iterates through the event list canceling those unnecessary 


events. 
F. SUMMARY 


In this chapter, we presented the details of the modeling a spread spectrum 
CDMA receiver. Limited modeling of synchronization was presented. We presented in 
detail the implementation of multiple access mechanisms, using OPNET. The details of 


despreading and decoding the information bits were also presented. 
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VI. SIMULATION RESULTS 


In this chapter we present an evaluation of the implemented system by 
Summarizing the simulation results obtained from the model. Both the Rayleigh fading 
and the standard Gaussian approximation (SGA) bit error rate (BER) models are 
considered to study the models’ channel characterization. We evaluate the multiple access 
capability of the receiver as a yardstick for the models’ CDMA capability and 
functionality. This evaluation incorporates proper PN code generation, spreading, 
despreading, decoding and decision making. 

The modeled system supports both voice and data users. As shown throughout 
this writing, a given user may generate more than one call of the respective type 
(N,,N,). The number of possible simulations is infinite. Complete verification of all of 
these aspects would be through intensive testing, simulation and evaluation. Here, we 
evaluate the networking aspects of this model by testing the system under two typical 
scenarios: 1) nodes consisting of speech users only, and 2) nodes consisting of data users 
only. 

We demonstrate the performance of the medium access control under the 
implemented slotted ALOHA MAC and CDMA physical layer. The measurement of 
performance would be the percentage of spread spectrum utilization of the channel 
capacity, which we term spread spectrum utilization. 

In presenting the models’ evaluation, we first offer a common baseline on which 
the simulations were based. A summary of the simulation parameters used is provided. 
Next, we present the results of the BER models. The third section offers a graphical 
presentation of the models’ CDMA capability. We conclude this chapter with an 
evaluation of the performance of the MAC under CDMA. 


A. SIMULATION SETUP 


In this section we review the simulation parameters for the model. A partial listing 
of the user definable parameters is given in Table 6.1. We note unspecified parameters or 


those that vary from the defaults as necessary. 
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Table 6.1. Baseline Simulation Parameters 


Active Sources Integer 
| SlotLengh_ | Double | 
= aljme Tivarhold | = Double | no 
[= Data Tieshold | _____ Double | __ 0 


As the models of [6] were developed in support of ATM research, here we chose 















similar packet formats as shown in Figure 6.1. The format consists of a synchronization 
frame of 1 octet, a 5 octet MAC header, and a 53 octet information packet. The 
processing gains (k) of each segment were 127, 31, and 31 respectively, giving a spread 
packet length of 15,400 chips. The PN codes were generated with a seven bit register, 
providing 18 unique PN codes and a processing gain of 127 for the synchronization 
frame. However, as the traffic models employed have an equivalent data rate of 
approximately 32 kbps, Equation (2.7) restricts k to 31. To compensate for this, we 
reduced the synchronization frame from four octets to one octet. Rather than spreading 
four octets by 31, we spread 1 octet by 127. This occupies approximately the same 
bandwidth, yet ensures the sequences generated for spreading the synchronization frame 
remain orthogonal. 

Including guard band time, the resulting slot length, T,, of the spread packet 1s 
approximately 13 ms. The subchannel capacity is given to be approximately 77 packets 
per second; the equivalent data rate is approximately 39.6 kbps or 1.228E6 chips per 
second. 
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Figure 6.1. Simulation Packet Format 











The channel is configured with the parameters listed in Table 6.2. As discussed in 
Chapter III, the Modulation parameter 1s irrelevant in this selection as we determine the 
BER directly without reliance on OPNETs’ internally defined BER tables. However, the 
user is required to make a choice. The value for ECC threshold allows the receiver to 


accept essentially all packets. 


Table 6.2. Transmitter/Receiver Channel Parameters 


The channel parameters closely resemble those of IS-95; see Table 9-2 of [10]. 
Shown are 60 subchannels per RF channel which is based on a data rate, R, , of 9600 bps, 


and a chip rate, R,, of 1.2288E6 chips per second. As the traffic sources have a data rate 










of approximately 32 kbps, NV, 1s restricted to 12. For the multiple access implementation, 


the receiver PN code matnx is defined using the following polynomials: R(3,7), 
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Rem eeR(1213.4050), R17), R67), RU,3,5¢7)P"R(1,255.7), ROB ASiouaT 
R(1,2,3,7), R(1,2,4,5,6,7), R(2,4,6,7), and R(1,2,3,5,6,7). 


The required channel capacity is 


N : 
C= re packets per second (6.1) 


5 


where JN, is the number of unique PN codes and 7, is the slot time in seconds. Thus, the 
channel capacity for the simulation is 
12 


Go Raise 925 packets per second. (6.2) 


The spread spectrum utilization of the MAC 1s then given by: 


_ Successfully Received Packets / seconds 


: (6.3) 


The numerator is calculated by dividing the number of successfully received packets at 
the receiver by the total simulation time (seconds), where we have defined successfully 
received packets as those packets that were successfully synchronized and were not 


considered PN collisions. 
B. BIT ERROR RATE EVALUATION 


In evaluating the modeling of the channel, we consider the Rayleigh fading model 
and the SGA BER as discussed in Chapter II. 


1. Rayleigh Fading Channel 


The results of the Bit Error and Error Allocation pipeline stages implementation 
of the Rayleigh fading channel BER are shown in Figure 6.2. The curve represents the 


average rate of errors injected from within the Error Allocation pipeline stage. The curve 
shows the dependency of the BER on the variation of the received E,/N,. A detailed 


treatment of fading channels can be found in [10]. The focus here is on the modeling of 
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such a channel within the OPNET environment. Figure 6.2 illustrates the impact of 
channel fading and the linear relation between the probability of error and £,/N,. 
Figure 6.2 shows plots of both the model results and Equation (2.11); however, the results 
produced by the model match so closely with Equation (2.11), the two curves completely 
overlap each other. Throughout the simulation, the calculated BER of the Bit Error 
pipeline stage and the average BER from injected errors within the Error Allocation 


pipeline stage are quite similar to theoretical expectations. 


Modeling the BER for Rayleigh Fading Channel 


Probability of Error 


i i 
+ i 
5 





0 5 10 15 20 25 
Eb/No (dBm) 


Figure 6.2. Rayleigh Fading Channel BER Simulation Results 


a Standard Gaussian Approximation 


The implementation results of the SGA model are shown in Figure 6.3. Plotted are 
the curves for K = 3, 6, 9, and 12 nodes within the network. The solid curve plots the 
theoretical BER as determined in the BER pipeline stage. The dashed line curve plots the 
rate of errors injected into the packets 1n the Error Allocation pipeline stage. As discussed 
in Chapter II, this BER modeling is for the case of a non-fading, noise limited channel. 
The results indicate the BER of injected errors closely parallels the theoretical 
expectations. 

The degradation suffered in a fading channel is apparent when comparing Figures 


6.2 and 6.3. This comparison highlights the importance of model selection when 
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designing a communications system. As the proposed system is essentially a cellular 


system, the Rayleigh fading model may provide the best realistic expectations. 


Model Theoretical vs Model Injected BER 
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Figure 6.3. Model Implementation of Gaussian Approximation 


C: CODE DIVISION MULTIPLE ACCESS SIMULATION 


In this section we evaluate the CDMA capability of the model. The simultaneous 
reception of multiple packets is illustrated in Figure 6.4. The constant rate traffic source 
was employed at a rate of 10 packets per second. The upper graph shows the 
accumulations of the total number of packets transmitted, the total received packets, and 
the total that were determined as successful receptions. The lower graph magnifies the 
beginning of the upper graph for clarity. Shown is the case of K = 18. E,/N, was set to 12 
(dBm) such that the probability of synchronization failure was essentially Zero, 
considering Tables 6.1 and 6.2. As shown, 12 of the 18 packets were considered 


collisions and were rejected. 


50 


20 
a3 
10 

: 


0 


koe Pye a 


eal 


MAC Departures 


TDS 


Cee ee ee 


Pern eee tn 


Total Received Pkts 
MAC Departures — 


~~ OTs Free 
Successful Receptions 
ge Spel Se 
rect mee Ty) 


ee — —E 


= me Multiple Access Reception 


<q— Total Received Pkts 


Collision Free, 
Successful Receptions 


eC 
Tine ¢s20> - 


Be eet ae ll 
roappenruonasuamnsavesaawonert] 


rr OU ee 





Cee ee ee ee eee ee ee Cas = Ca 


Figure 6.4. Hlustration of Multiple Packet Reception 


D. 


EVALUATION OF MAC PROTOCOL PERFORMANCE 


Here we discuss the way the MAC performance (n) is measured and analyze the 


performance of the slotted ALOHA MAC protocol. We test two cases representing 


typical scenarios in the 


military environment: a pure speech network (representing 


traditional voice networks), and a pure data network (representing new networks for fire 


control, C’I, battlefield dominance, etc.). In each scenario, we analyze the spread 


spectrum utilization of the protocol under various traffic loads. 
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1. Speech Traffic 


The speech model generates traffic at a mean rate of 75 packets/second. Since the 
subchannel capacity is approximately 77 packets/second, for a single user of a given PN 
code, the spread spectrum utilization should be approximately 97%. 

The simulation results for the pure speech scenario are shown in Figure 6.5. We 
see that for up to 12 users (N,), the spread spectrum utilization, n, rises almost linearly 
up to approximately 97%. This is to be expected as all PN codes are unique up to this 
point and there are no collisions in any of the subchannels. For every additional user 
beyond N,, we see dramatic degradation in 7 as the subchannels are no longer used by a 
single user. The high spread spectrum utilization of the subchannel of a single user 


(approximately 97%) also contributes to the degradation. 


Spread Spectrum Utilization of Two Way Conversation 
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Figure 6.5. Spread Spectrum Utilization with Voice Traffic 


De Data Traffic 


The data model generates traffic at a mean rate of 3.85 packets per second, per 


data source. The subchannel capacity remains the same as above at approximately 77 


a 


packets per second. As each node was simulated with 10 sources per node (NV, =10), n 


3.85 x 10 
of a single subchannel is expected to be a or approximately 50%. From Figure 


6.6, consider the result for K = 12. With each node utilizing a unique PN code (thus a 
separate subchannel) for 50% of the time, we observe that the spread spectrum utilization 
is slightly less than 50%. 


Spread Spectrum Data Utilization 


eas eee tees ene oe 
See esa eee 


SS Utilization 


\ 
| 
! 
] 
1 
1 
\ 
1 
| 
| 
1 
| 
| 
| 
| 
I 
] 
I 
{ 
1 
| 
I 
I 
! 
I 
I 
I 





0.6 0.8 12 
Load 


Figure 6.6. Data Utilization Under Heavy Loads 


Now suppose that traffic from two different nodes is spread equally in time. As 
each data node multiplexes 10 bursty data streams, we can assume a Poisson behavior for 
the combined stream [18]. Therefore, the expected spread spectrum utilization for the 


case of two users per PN code is: 
1 =Prfonly PN user | transmits} + Prf{only PN user 2 transmits} 
We have shown above that the spread spectrum utilization of each user is approximately 


50%. Assuming that the traffic patterns of all users are similar, the spread spectrum 


utilization, n, given that two PN Codes are used, can be shown to be 
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n° =2 x Pr{only PN user | transmits} 

= 2 x Pr{PN user | transmits} x(1 — Pr{PN user 2 transmits} ) 
2x 0.5 x (1 — 0.5) 
= Nee 


Figure 6.6 indicates that the measured results compare with the above analysis. For 
example, for K equals 24, the spread spectrum utilization is approximately 50%. We can 
easily extend this analysis to the case of 3 users per PN Code. Based on the above, the 


spread spectrum utilization can be shown to be 
Vy =3x0.5x(1-0.5)" =37.5%. 


From Figure 6.6, for K equals to 36 nodes, the measured spread spectrum utilization is 


approximately 37.5%. 
E. SUMMARY 


In this chapter we presented simulation results of the implementation of the 
proposed model in OPNET. BER performance of the RF channel has been studied for 
both the Rayleigh fading channel and the SGA. Spread spectrum utilization performance 
of the MAC protocol with an underlying spread spectrum CDMA physical layer was 


measured. 
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VII. CONCLUSIONS AND RECOMMENDATIONS 


A. CONCLUSIONS 


The objective of this thesis was the OPNET modeling and implementation of a 
CDMA system for the uplink transmission of a single cell network. To meet this, we 
implemented traffic generation, slotted ALOHA medium access control, spread spectrum 
transmission and (multiple access) reception, and the RF channel processes in OPNET. 
Also addressed were the issues of packet formatting, time slots within the MAC, packet 
spreading, bit manipulations of the packets within the BER and Error Allocation pipeline 
stages, and proper despreading of the packet in the receiver. 

The proposed system consists of three major modules: the transmitter, the 
channel, and the receiver. We implemented all three modules in OPNET. As part of this 
effort, we were able to use some OPNET supplied modules (with minor modifications), 
but we developed several other modules as their functionality was not available in 
OPNET. 

As part of the transmitter module implementation, we developed the appropriate 
traffic generation, slotted ALOHA MAC protocol, PN code generation, and spreading 
modules. The channel was implemented utilizing OPNET’s fourteen stage pipeline 
architecture. The different pipeline stages had to be appropriately configured to realize 
two channel models: SGA and Rayleigh fading. The significant effort here consisted of 
developing the corresponding BER models and injecting errors into packets accordingly. 

The receiver implementation consisted of (simplified) synchronization, packet 
despreading, and packet decoding modules. The functionality of these modules are not 
readily available in OPNET, hence they were coded and integrated into the model. 

The designed system was then simulated, and some performance results were 
obtained. The bit error rate performance of the system was measured for both SGA and 
Rayleigh channel models. The measured results agree well with theoretical results. The 
multiple access performance of the MAC protocol under CDMA was studied by 
measuring the spread spectrum utilization performance. The measured results were 
obtained for both voice and data traffic, and they closely match with the expected 


theoretical performance. 
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B. RECOMMENDATIONS FOR IMPROVEMENTS 


This modeling effort was designed to be a starting point, offering a foundation 
upon which the proposed communications system might be built. Future work on this 
model might consider the implementation and evaluation of mixed data and voice traffic, 
node mobility, power control issues, queuing algorithms, and receiver feedback issues as 
potential areas of expansion. 

Based on the experience of this effort, we conclude that OPNET’s modeling 
software is an excellent tool for wireless network design and simulation. It was a difficult 
task to understand and utilize OPNET’s modeling tools; but once we mastered their basic 


usage, we found them to be indispensable for any network modeling effort. 
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APPENDIX A. AN OVERVIEW OF OPNET 


In this appendix we provide a brief overview of the OPNET modeling software 
package. This appendix reviews the OPNET hierarchy, the concept of OPNET’s 
simulation kernel, the employment of interrupts within an OPNET simulation, and the 
definition of an OPNET process module. The objective here is to familiarize the reader 
with the basic workings of OPNET. The reader requiring a more detailed or extensive 
treatment of OPNET’s modeling software package is referred to the 12 volume set of the 
OPNET user manuals. 


A. THE OPNET HIERARCHY 


OPNET is a comprehensive engineering system capable of simulating large 
communications networks with detailed protocol modeling and performance analysis. 
OPNET is hierarchical in that it implements models in three levels: the network level, the 


node level, and the process level. The hierarchy can be envisioned as shown in Figure 


A, 1. 
Network Model 


Node Model Node Model 
Process Process Process Process Process Process 
Model Model Model Model Model Model 


Figure A.1. OPNET Hierarchical Organization 


At the network level the modeler defines the bounds of the network. The network 
model may represent a single network or numerous subnetworks. The network model is 


defined by one of the underlying node models. 
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The node models are defined by queues, generic processes, traffic generators, 
transmitters, receivers, antennas and other modules available within OPNET. Figure 5.1 
offers a graphical view of the receiver node model implemented in this thesis, and is 
repeated here as Figure A.2. As shown, it consists of an antenna module, a radio receiver 
module, and two user defined processes. The PN DESPREADER process and the SINK 
process are two examples of generic processes which the designer has full flexibility in 
designing. Implementing these generic processes is commonly where the full modeling 
capability of OPNET 1s realized. 





radio_antemna radio_rev PN_DESPREADER $ ink 


Figure A.2. OPNET Receiver Node 


The arrows connecting each module of Figure A.2 play a major role in OPNET. 
They are referred to as streams. The radio_antenna module has one output stream. The 
radio rcv module and the PN DESPREADER process module have one input stream and 
one output stream. The SINK process module has one input stream. The interconnecting 
streams are the primary communication link between the different process modules 
within the node. To understand their use, we review OPNET interrupts and OPNET’s 


simulation kernel. 
B. INTERRUPTS AND THE SIMULATION KERNEL 


OPNET’s simulation kernel (SK) can be considered the master scheduler and the 
master clock within OPNET simulations. OPNET 1s a discrete time, event driven system. 
The time axis within an OPNET simulation is referred to as sim_time(). A sim_time() 
equal to 0.0 indicates the beginning of the simulation. As simulations are executed 
within OPNET, sim_time() advances and there are a series of events which become 
scheduled to occur at different times throughout the simulation. Typical events might 


include the sending of a packet every X number of seconds, sampling a queue size 
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periodically, decrementing a counter or a number of other events the designer has 
defined. The SK is responsible for scheduling these numerous events and ensuring they 
are executed at the scheduled sim_time(). 

The various scheduled events are typically executed by the invocation of different 
processes which define the process modules; the process of despreading is executed by 
the invocation of the PN_DESPREADER process module shown in Figure ALI 
Processes are typically invoked into execution by one of two methods; 1) sim_time() 
reaches the time the process is scheduled to be invoked, and the process is automatically 
invoked into execution, or 2) OPNET’s SK alerts the process by sending an interrupt to 
the respective process via an input stream. The interrupt delivered to the process invokes 
the process into execution, and the functions of the process are carried out according to 
the definition of the process. From the designers perspective, interrupts are the most 
common method of invoking processes into execution. 

The focus of modeling in OPNET is in defining the process models (processes) 
which support and implement the node model. The process models are implemented as a 
Finite State Machine. The Finite State Machine is defined by completing a state transition 
diagram which defines the various states of the process and the transitions that 
interconnect each state. Figure 5.2 portrays this model’s PN DESPREAD process. Figure 


A.3 portrays the same process as viewed from within the OPNET graphical environment. 
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Figure A.3. OPNET View of PN_DESPREADER Process Model 
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Cc DEFINING THE PROCESS 


1. OPNET’s Graphical User Interface (GUI) 


As seen from Figure A.3, the PN DESPREADER process consists of four states. 
The actions performed within each state are dictated by the designers source code (written 
in C). In completing the source code for a process, the column of icon buttons on the left 
side of Figure A.3 play an important role. 

The icon buttons Network, Node, Process, Parameter, Probe, Simulation, 
Analysis, and Filter remain visible in the OPNET window throughout execution of the 
OPNET program. These icon buttons determine the level (Network, Node, Process) at 
which the designer will work, or they allow the designer to define Parameters, Probes, 
Simulations, perform Analysis’, and define Filters. The reader interested in these areas is 
encouraged to consult the OPNET user manuals for a detailed description. 

The icon buttons on the lower half of the column are specific to the OPNET level 
which is in view. For example, selecting the Process icon button from the level selection 
indicates the designer wishes to work at the Process level within OPNET, and is thus 
presented with the process level icon buttons as shown in Figure A.3. A magnified view 
of these icon buttons is shown in Figure A.4. 

The process level icon buttons are used for writing the C source code which 
defines the behavior of the process. Selection of either of the HB, TV, SV, FB, DB, or TB 
icon buttons will invoke the OPNET editor from which the designer enters the relevant C 
source code. The HB icon button 1s used for defining the header block of the source code. 
The TV icon button similarly defines the temporary variables of the process. The SV 
icon button defines the state variables, and likewise FB defines the function block, DB 


defines the debug block, and TB defines the termination block for the process. 
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Process 
Level 
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Figure A.4. Process Level Icon Buttons 


The header block is similar to a C include.h file; #include <> statements and 
#define statements are likely to be coded in the header block. Temporary variables are 
declared in the temporary variables block and are not persistent variables, they exist only 
during the current invocation of the process. State variables are declared in the state 
variables block. They are persistent and retain their value from one invocation of a 
process to the next. For example, this despreader process is invoked every time a packet 
is received at the receiver. Any defined temporary variables are persistent only for the 
processing of this specific packet. Any state variables are persistent for all packets, as 
state variables are persistent throughout the simulation. A loop counter is an example of a 
common temporary variable. State variables are similar to static variables in C. 
Accumulators are a common example. 

The function block is where the designer defines the various functions used in the 
process. The functions are typically called from one of the states, but can of course be 
called from another function. A common approach is to minimize the code within the 
states so that they are defined primarily by a series of function calls, and to off-load the 
bulk of the processing to the various functions defined in the function block. The debug 


block and the termination block will not be discussed here. 
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pap Forced and Unforced States 


There is significance to the different color shading of the states shown in Figure 
A.3. States within OPNET are either forced or unforced states. Unforced states are 
transparent in color, forced states are opaque. A forced state is synonymous to an atomic 
instruction; it allows no interruptions during it’s execution. A forced state controls the 
simulation until it has completed it’s actions; it cannot be interrupted by the SK. An 
unforced state, on the other hand, returns control of the simulation to the SK once the 
process has entered an unforced state. A process which is in an unforced state is merely 
waiting another invocation call from the SK. 

Once the SK has regained control of the simulation from the process (indicating 
the process is in an unforced state), the SK is free to invoke other processes of the 
simulation. The key difference between forced and unforced states is that there is no time 
lapse between entering and exiting a forced state; all actions within a forced state are 
essentially executed at the same time. With an unforced state, the time between entering 
and exiting the state is determined by the overall simulation and the different processes 
involved. The transparent IDLE state indicates it 1s an unforced state. The remaining 
Opaque states indicate they are forced states, and will not be interrupted by the SK until 
they have completed the processing they are defined to perform. 

As an example of the above discussion, let us consider the despreader process 
defined by the state transition diagram of Figure A.3. At the beginning of the simulation, 
the INIT state is evaluated and initialization of the process is performed. Chapter V 
outlines the actions performed in this particular INIT state. As the INIT state is a forced 
State, all actions within this state will be performed at the beginning of the simulation 
without any interruption from the SK, and without any elapsed time. Upon completion of 
initialization, the process is forced into the IDLE state. As the IDLE state is an unforced 
state, control of the simulation returns to the SK, and as no time lapse was incurred 
during the initialization, sim_time() = f¢, indicating the simulation time clock 
(sim_time()) has not advanced. 

Upon regaining control of the simulation from the despread process, the SK 
checks the event list. The SK determines the next scheduled event and the time that this 
event is scheduled to occur. The SK will then notify the relevant process at the 
appropriate time. The SK’s notification to a process is typically performed by delivering 


an interrupt to the respective process. 
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3. A Packet Flow Example 


Consider the flow of a packet from transmission to reception. At some point in 
time the transmitter transmits a packet. The packet is evaluated by the pipeline stages, and 
the SK determines the time at which the packet is scheduled to arrive at the receiver, say 
The SK then schedules a stream interrupt (OPC_INTRPT STREAM) to be 
the SK 


delivers a stream interrupt to this despreader process. This delivered interrupt will invoke 


aaa i 


delivered to this process at this same arrival time, £ At sim_time() = ¢ 


arrival ° arrival ? 


this process into execution (assuming the process is in an unforced state). 

We have seen where the despread process performed the initialization functions at 
the beginning of the simulation, then transitioned to an IDLE state. Thus, at the time that 
the SK delivers an interrupt to this process (sim_time() = 1,,,,,,, ), the despread process is 
‘resting’ idly in the unforced IDLE state. Within the header block of this process, we 


have the following definitions: 


/* Header Block Definitions */ 

#define SYNC ACHIEVED 1 

#define PKT RECEIVED  (op_intrpt_type() = = OPC_INTRPT STREAM) 

#define ACHIEVE SYNC (op _intrpt_type() == OPC_INTRPT_ SELF && 
op_intrpt_code() == SYNC_ACHIEVED) 


The SK delivered interrupt invokes the execution of this PN DESPREADER 
process. Thus, at sim_time() = ¢,,,,, this despread process begins execution. Upon 
execution, the process determines.that PKT RECEIVED evaluates to a TRUE condition 
(the interrupt just delivered is equal to a stream type interrupt) and will thus transition to 
the SYNC state (see Figure A.3). 

As the SYNC state is a forced state, it will execute the code defined within the 
SYNC state without interruption from the SK. The source code implementing the SYNC 


state is similar to: 
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/* Sync State implementation code */ 
packet = get_packet_from(incoming_packet_stream); /* get the incoming packet */ 
do { 
for(ix = 0; ix < upper_limit_1; +4+1x) { 
for(jx = 0; jx < upper_limit_2; ++)x) { 
correlation value = cross_correlate(packet, pn_code); 
if(correlation_value = sync_threshold) { 
achieved_sync = TRUE; 
store _packet_in_list(packet_safe_keeping list, packet); 
fo erie its oy 
\ /* end inner for loop */ 
\ /* end outer for loop */ 


} while (!(achieved_sync || all_ pn_codes_have_been_checked)); 


From the above block of code, we see the use of several variables. The loop 
counters ix and jx are temporary variables and are declared in the TV block. Likewise, 
packet is a packet pointer (Packet *) and 1s a temporary variable. It is also declared in the 
TV block. The variable packet_safe_keeping list represents a linked list which stores 
packets that have achieved synchronization. As we need this list to be persistent, it is 
declared in the SV block as a state variable. The functions get packet_from(), 
store_packet_in_list(), and cross_correlate() are defined in the FB of this process. 

We see from Figure A.3 that the SYNC state has only one transition leaving the 
state. This transition is an unconditional transition, which is indicated by the solid line 
and the lack of any conditional statement above the transition. Upon completion of the 
actions within the SYNC state (i.e. executing the above block of code) the process 
unconditionally transitions back to the DECODE state. As DECODE is an unforced state, 
control of the simulation is then returned to the OPNET SK. The SK will again evaluate 
the event list, determine the next scheduled event, and send an interrupt to the respective 


process, and the simulation continues in a like fashion. 
D. SUMMARY 


Here we have provided an overview of the OPNET modeling software. We 
reviewed several OPNET specific terms. We noted that the OPNET simulation kernel 
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(SK) might be considered the master scheduler and the master clock, and we noted that 
the SK communicates with the different processes by sending stream interrupts to the 
respective process. We outlined the differentiation between forced and unforced states 
and reviewed how control of the simulation is passed to the process while within a forced 
state, and is then returned to the SK once the process returns to an unforced state. With 
this overview, the reader 1s provided a basic understanding of the OPNET modeling 


software package. 
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APPENDIX B. PIPELINE SPECIFICS 


The objective of this appendix is to present an overview of the OPNET pipeline 
stages and review the details of the Interference, the SNR, the BER, and the Error 
Allocation pipeline stages. This appendix is intended as a supplement to Chapter IV and 
is not written to stand alone; it should be consulted as necessary after reviewing Chapter 
IV. We assume the reader is familiar with the OPNET modeling software and has 


reviewed Appendix A as necessary. 
A. PIPELINE STAGES OVERVIEW 


OPNET Pipeline stages are user coded (or OPNET defaults) C functions that are 
used to model an RF channel. Most of the stages are executed sequentially as is implied 
in Figure 4.1. The stages query information from packets in a variety of ways, which we 
will soon show. In executing several of the stages there is no time lapse incurred, i.e. the 
invocation of several stages are scheduled for the same time and are ‘stacked’ on each 
other in the event list. Simulation time ‘stands still’ during the sequential execution of 
these stages. The SK manages the scheduling and invocations of the stages, and the 
designer need only be concerned with the actual coding of the C functions to properly 
characterize the channel according to the user’s model. 

When a process sends a packet through a radio transmitter, the SK realizes the 
need for the pipeline stages. The SK will schedule in the event list a number of function 
calls to invoke each of the pipeline stages at the appropriate time. When the SK invokes a 
pipeline stage, the packet to be evaluated is automatically passed to the user defined C 
function which implements the pipeline stage. 

An OPNET specific term used throughout Chapter IV 1s TDA, which represents 
Transmission Data Attribute. TDA’s are fields within the packet which are used to store a 
variety of informational values pertaining to the packet. TDA’s have a bit length of zero, 
meaning the length of the TDA field is not considered in any pipeline calculations. 
TDA’s are place-holders of information. There are numerous TDA’s defined within 
OPNET. Most of the TDA’s are for the exclusive use of the SK. Most all the TDA’s can 
be read, but only a small minority of them can be written to by the pipeline stages. 

Packets do not have TDA’s until they are transmitted from a radio transmitter 


(meaning they can be queried in the receiver process, but they don’t yet exist in the 
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spreading process). The SK establishes and sets the appropriate values for a number of 
TDA’s once a packet has been sent from a radio transmitter, and not until. 

As pipeline stages are invoked by the SK, the pipeline stages perform their 
requisite calculations and insert the result(s) into the respective TDA of the packet. Later 
stages will often make their calculations based on the value(s) set in a particular TDA 
from a previous stage. Thus, the pipeline stages can be considered sequentially executed 
C functions which read and set values of the packet’s TDA’s. The inclusive set of 
pipeline stages allow the designer to completely model an RF channel and to report the 


channel’s characterization via the TDA’s. 
B. INTERFERENCE AND SNR SPECIFICS 


In this section we review the details of implementing the Interference, the SNR, 
the BER, and the Error Allocation pipeline stages. To properly model this proposed 
system, it is critical to fully understand how these pipeline stages are invoked and at what 


respective times they are invoked by the SK. 
1. Interference Noise Calculations 


The Interference Noise stage is the only pipeline stage which receives two packets 
from the SK. Upon invocation of this stage, the SK automatically passes both packets of 
interest to this pipeline stage. 

Interference as defined here indicates simultaneous reception of packets. 
Interference is caused by the overlapping reception of packets at the receiver and occurs 
for a packet in two instances: 1) a packet is being received and another packet arrives, or 
2) a packet arrives when another packet is being received. Figure B.1 depicts an example 
of three simultaneously arriving packets. In this example, this pipeline stage will be 


invoked three times. The reasoning follows. 
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time 





Start RX END RXp END RX, END RXc 


Figure B.1. Multiple Packet Reception and Respective Noise Levels 


The SK orders simulation events in an arbitrary manner. There are 
typically several events scheduled simultaneously. In the above example, at least three 
events are scheduled for time t, = START_RX; the arrival events of each packet. Due to 
the arbitrary ordering of events, the SK must select one of the packets as the first 
received. Simulation runs indicate the SK selects the packet with the lowest numerical 
packet id (pkt_id) as the first arriving packet. Packet id is an internal attribute defined by 
the SK. The designer cannot set or modify this attribute. 

Consider for example Figure B.1. Here we assume pkt_id(B) < pkt_id(A) < 
pkt_id(C). In this example, the Interference Noise stage will be invoked first with packets 
B and A due to packet A’s interference on B, again with packets B and C due to packet 
C’s interference on B, and finally with packets A and C due to packet C’s interference on 
packet A. 

Note also that when a packet completes reception (END RX), the SK 
automatically subtracts the completely received packets accumulated noise power from 
any packets still being received. In the above case for example, this pipeline stage will 
not be re-invoked at time t = t,. The interfering noise power TDA (NOISE_ACCUM ) of 
packets A and C will however reflect the correct noise power due to interference: N, = 


P,, and likewise N, = 0 as there is no interference during this packet segment. Equation 


(4.8) shows the noise power calculation employed by this model. 
De Signal-to-Noise Ratio 


The SNR pipeline stage is invoked for packet a due to one of three conditions: 1) 


a packet begins reception, 2) a packet is being received and another packet arrives, or 3) a 
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packet is being received and another packet completes reception. Essentially upon a 
packets arrival at the receiver, or upon a collision. 
For the example shown in Figure B.1, the SNR stage will be invoked for packet A 


three times (assuming the SK assigns packet B the lowest numerical packet id). Packet B 
will invoke the SNR stage first at time t= t, due to condition 1 (B arrives); a second time 


at time t = t, due to condition 2 (A arrives), and a final time at time t = t, again due to 
condition 2 (C arrives). Similarly, packet A will invoke the SNR stage first at time t = t, 
due to condition | (A arrives), and a second invocation at time t = ft, due to condition 2 (C 
arrives). The third invocation 1s at time t= t, due to condition 3 (B completes reception). 
Finally, packet C will invoke the SNR stage first at time t = t,due to condition 1(C 
arrives), a second invocation at time t = t, due to condition 3 (B completes reception), and 
a third invocation at time t = t,, again due to condition 3 (A completes reception). 

Essentially, the packet is assigned a segment SNR based on the background noise 
during the segment interval. This models’ implementation determines SNR strictly based 
upon the background noise N, as shown in Chapter IV, and the differing levels of 
interference noise, N,, are not utilized within this SNR pipeline stage. We include the 
previous discussion as it applies in the general case. Although this model employs 
packets of equal length, it can be employed for packets of varying lengths. 

Recall upon an interfering packet completing reception, the SK will automatically 
subtract its received power from the noise accumulator (NOISE ACCUM TDA) of any 
packets still being received. Effectively N, and N, from Figure B.1 are internally 
modified by the SK and the values reported in this pipeline stage will reflect the noise 
level due only to interfering packets. 

Prior to leaving the SNR pipeline stage, a time stamp is placed on the packet. This 
time stamp is set in the TDA SNR_CALC_TIME and indicates the last time at which this 
particular packet visited this stage. In essence, it defines a packet segment of differing 
SNR levels. The SNR is held constant over the duration of any one segment. This 
parameter is necessary in the later BER and Error Allocation pipeline stages. 

The primary contribution of determining the SNR is its effect in determining the 
bit error rate (BER) of the channel. The BER 1s a key benchmark in channel analysis, and 


we now consider this model’s implementation of the BER pipeline stage. 
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C. BIT ERROR RATE SPECIFICS 


Arguably one of the most critical components of channel characterization is the 
BER. The BER may be a function of several parameters, depending on the channel model 
used. The BER may be a function of the type of signal modulation used, a function of 
interference noise encountered over the channel during transmission, or a function of the 
amount of white noise present, or some combination. Determining the channel BER and 


properly injecting the errors accordingly are key focal points of this effort. 
1. BER Pipeline Stage Invocation 


The relevance of the discussion in the interference stage concerning the timing of 
pipeline stage invocation may become more obvious with what follows. Understanding 
the timing of the pipeline stage invocations is critical in determining the correct BER. 

Similar to the interference noise stage and the SNR stage, the BER pipeline stage 
may be invoked for a valid packet for one of three reasons: 1) the packet completes 
reception, 2) the packet is being received and another packet arrives, or 3) the packet is 
being received and another packet completes reception. With the continued assumption 
that packet B is assigned the lowest pkt_id by the SK, and following the discussion of the 
interference and SNR stages, we realize the specific times each of the following packets 
will invoke the BER stage. Viewing Figure B.2, we can ascertain from the previous 


discussion and the conditions just listed that each of the three packets will 





to t i t 


Start RX END RX, END RX, END RX- 


Figure B.2. BER Pipeline Stage Invocation Events 


7] 


invoke the BER stage three times. Table B.1 offers a synopsis of the times and the 
condition (number 1, 2, or 3 above) which is met to cause the invocation. As the BER isa 
function of the number of XK interfering users, we require the instantaneous count of 
interfering users on any particular packet segment. 


The interference stage informs us of the number of interfering users, but only at 


Table B.1. BER Pipeline Stage Invocation Times and Conditions 


___Packet___——|_—InvocationTimes__|_ Respective Conditions _ 
| tos ty ty 
ett 
tne ty ty 


the onset of interference. Packets may invoke the interference stage numerous times, but 
only at time t = ¢, (START_RX). Too, OPNET’s SK will automatically subtract the 


power contribution (P.) of packets completing reception from any packets still being 










received. As the BER is not strictly a matter of SNR, we must determine WHY this stage 
is invoked each time the SK invokes this pipeline stage. 


23 Conditions of Invocation 


We implement this stage of the pipeline by evaluating three different times for 
each packet; 1) time t= START_RX (time of starting reception), 2) time t= END RX 
(time of ending reception), and 3) time t = the current simulation time. Recall that each 
packet maintains numerous TDA’s. START RX and END_RX are two of these, and the 
SK automatically determines and sets these values in each respective packet. With the 
intent of fully clarifying the implementation, let us walk through the BER calculation for 


packet B (we continue our assumption of packet B having the lowest id): 


Case 1: The first time we see packet B is at time t = ¢, due to condition (2), 


packet A arrives at the receiver. We check the SK master clock, sim_time(), and we 
check the packet’s START RX. We see they are the same, thus BER = 0. This is accurate 
in that we are at the leading edge of the packet, the segment length = 0, and thus there are 


no bits in error. 


WZ 


Case 2: The next time we see packet B is again at time t = t, due to condition 


(2), packet C arrives at the receiver. Again, a time check indicates we are just starting 
reception; BER = 0. 


Case 3: The final time we see packet B is at time t = t, due to condition (1), 
packet B completes reception. We check the SK master clock and we see that we are past 
START RX. This indicates either we have finished reception (condition (1)), or another 
packet has completed reception and forced this packet to invoke this pipeline stage again 
(condition (3)). We must determine which of the two cases holds true. 

Next we check packet B’s TDA (NUM_COLLS) to determine if the packet 
suffered any interference from the interference stage. As the BER is a function of K (the 
number of multiple users), we now have K = NUM_COLLS + 1, the one being ourselves. 
From this, we can determine the packet’s BER as shown in Chapter IV. The determined 
BER is set in the respective packet’s TDA. Prior to leaving this stage however, we must 
determine why this packet invoked this stage. 

If the current time is equal to END_RX, then we are here due to condition (1). No 
action is required, as this packet is completely received and the BER is properly 
determined. If the time comparison shows we are not finishing reception (current time < 
END RX), then we must be here due to condition (3): another packet has completed 
reception. This indicates we will invoke this stage at least once more. But this packet now 
has one less interfering user. We must adjust the TDA (NUM_COLLS) to reflect this. We 
decrement NUM _COLLS by one to reflect the fact that an interfering packet has been 
completely received and is no longer interfering with this packet’s reception. Note, the 
BER was determined prior to decrementing NUM_COLLS. 

We can follow this logic through for packets A and C and we will find the results 


are the same. Rather, we offer a summary in the concise form of simple pseudocode: 


if(time t= = START_RX) 
BER=0 
else 
BER = f(K), where K= NUM_COLLS +1 _/* Rayleigh or SGA dependent */ 
end if 
if(time t< END_RX ) /* another packet finished sf 
decrement NUM COLLS /* set it up for the next visit */ 
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Each invocation of the SNR stage defines a packet segment which will have its 
own segment SNR and segment BER as shown in Figure B.2. As we have seen in some 
cases, the segment length is zero. In others, it may be equal to the packet length. What is 
critical is determining the correct value of K. 

The next objective is to inject the errors within each packet as determined from 
the BER stage. The Error Allocation pipeline stage is the BER injector, and is the next 


pipeline stage for review. 
D. ERROR ALLOCATION SPECIFICS 


The OPNET default error pipeline stage provides an error allocation approach 
which is accurate and efficient in terms of simulation time requirements. The OPNET 
manuals offer a detailed discussion of the algorithm used, and that approach is quite 
satisfactory for the general case [17]. In this model, we necessarily part from the default 
stage in that we must specifically test each bit of the packet against the probability of an 
error. 

The majority of the necessary work has been accomplished in previous stages. 
The packet that arrives to this stage will have no less than one SNR segment and no less 
than one BER segment. Recall that each visit to the SNR stage defines a packet segment. 
Equivalently, each SNR pipeline stage invocation will cause an invocation of the BER 
pipeline stage which also defines a packet segment. 

What remains to be done 1s to physically inject errors according to the determined 
BER. The BER was set in the packets TDA (BER) from the previous stage. This model 
implements this Error Allocation pipeline stage by querying the set BER and determining 
the effected packet’s segment length. We sequence through the respective packet segment 
randomly inverting bits throughout the segment. The pseudocode showing this approach 
is presented in Chapter IV. 


E. SUMMARY 


In this appendix we provided an overview of the OPNET pipeline stages and 
reviewed the specifics of the Interference, the SNR, the BER, and the Error Allocation 
pipeline stages. To correctly model this system, the designer must fully understand the 
timing of the invocations of the different stages, as they greatly impact the model. 
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APPENDIX C. CONSTANT TRAFFIC GENERATOR SOURCE CODE 


In this and the following appendices, we list the source code implementing this model. The code is 


-ommented throughout where appropriate. 


OPNET CODE FOR CONSTANT RATE TRAFFIC GENERATOR 


Header Block 
Roger Standfield 
November 1997 
roger .standfieldémctssa.usmce.mil 


BeHeader Block Code */ 
mnclude "mobile.h" 


‘define FALSE 0 
fetine TRUE 'FALSE 


maefineMAX LENGTH OF USER_INPUT BITS 10 

‘define ENDSIM INTRPT (op_intrpt_type () == OPC_INTRPT_ENDSIM) 
‘define GENERATE PKT (Opminerpt type ()) =S—O8C Thiet Sorin) 
MefineUPLINK STREAM 0 


meee * Function Prototypes *****/ 

mcern void Preint the pkt(Packet*™ pkptr); 

mat Beevert data(short arrayl[], char array2{]); 
mecket* @ease Gata packet (short data bits array|}); 
mee * Global Variables *****/ 

meleanfinal scalars written = OPC_FALSE; 

at debug; 


nt mri t S > 


mt Eoeeeesource pkts sent; 


State Variables Block 


Mecribution* \ia dist ptr; 


bjid \my id; 

shar \user data bits [MAX LENGTH OF USER INPUT BITS]; 
mort \data_array[DATA BITS]; 

louble \gen rate; 

oat \user data bit length; 

amt \pkts_generated; 


fi 


Temporary Variables Block 


Packet aeikptr -aedaga pkptr; 
double Gorceee tine, 

19) 6 exe 

SHOE Gir were: Oe Gee le leet, 
(@) cinualre| DGC 1 yun Daienieamlnews 


Function Block 


Packet* createsdatampackem(shememdata bits array) 
{ 

short *data bit pt rae Poieme eis, 

eeouble ~pkE credt Pom werc, 

Packet *data pkptr; 

Boeclean cata Dktimereatees— Ober Alot, 


 TECtal Sounce pkESmscnt ; 


data _pkptr = op pk create fmt("DATA PKT"); 
Pe (Gdta pkpeee =s(haeket ~) OPE NI i} /* we need to ensure we have */ 
/ * SA GeOdme ke. <7 


{ 


PREPeGuedta on time, — Op pk credtion time gea(datampkere uy 

/* now get us some place to store all of this data? - 

data bit ptr = (Short *) op prg_mem alloc(DATA BITS*sizeot(chocmur 
PE(Adtate eee per '—eKshore ~)hOPCINIL) /* cool. we have a pke +7 


/* and a storage spot 
{ 
/* now we can take the data_array[] created in the INIT */ 
/* state and do a block copy of all those data bits into */ 


/* our newly allocated storage spot. Then we'll insert. a 
/* the address of this storage spot into our data pkt, <p 
/* effectively ‘encapsulating' the data into the pkt. x / 


/* OPNET gives us the tools to make life a little easier, */ 
/* just as well use them. unfortunately, this function * | 
/* call returns void, making error checking and trapping */ 
/* rather labor and processing intensive. trust the fact 


/* that this was tested and verified during the sa 
/* debugging and testing stage of this development. 7 
/* We can do a similar operation strictly with C code, * / 
/* but we're better off keeping in the OPNET environment, */ 
/* as their memory allocation is customized for this a 
/* software. ea: 


Spmprg mMemecopy (data bitsiarray,. datdvotegemn: 
DATA BITS*sizeof (short) ); 


/* now put the PO Box #, ie the address, of this memory */ 
/ locaton into the pkt a 


t£(op pk nfd set(data pkptr, "DATA", data bit ptr, 
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Op_prg_mem_copy_ create, op_prg mem free, DATA BITS*sizeof (short) ) 
OPC _COMPCODE _SUCCESS) 


if (op pk nid set( data ipkper, ee eens 
pkt_ creation time) == OPC _COMPCODE _ FAILURE} 
Spy saan _message("ERROR: TRAFFIC GENERATOR: 
send ycel Comac (jee, 
a oGuae Teer Pkt creation time in@eres ELE 
data may be bogus. Le 


data _pkt_created = OPC TRUE; /* we've made it all the way */ 
/* ere, Set cay) ceor, samme. 
} 
else feebe the insertion of the address) favleqd ee tressuoeti */ 
/* memory that was allocated * / 
{ 
Sempeg mem £ree(data bit ptr) ; 
oo SLM _message("ERROR: TRAEEIC GENERATOR Create Gauaep iin 
“Pe LtLURE TO INSERT DATA BIT ADDRESS!") ; 
} 
} 
else /* if the memory allocation for the data bits failed, the eee 
fee pKkt is of no use. trash it. 7) 
{ 
Seepk cestroy (data pkptr); 
Aeon message ("ERROR@ERAFFIC GENERATOR: create data pkt(). 
"FATLURE TO ALLOCATE MEMORY FOR DATA Tae 


/* at this point, we either have a created data packet or we don't. If */ 


/* data pkt create == TRUE, we're golden. if == FALSE, the something ze], 
/* went wrong along the way. If this is the case, allocated memory has */ 
/* been released case, allocated memory has been destroyed ensuring a 
/* we don’t have a build up of unused pkts. ao) 
/* only need to return the results to the calling function. ys 


1f(data_pkt_created) 
Beeurn(data pkptr); 
2alse 
{ 
Seeocim message ("ERROR: create data pkt(): Failed to create Data Pkt.", 
een) ° 
meeurn( (Packet *) OPC NIL); 
} 
} /* end create data packet() */ 


[RR KK KK KK KK RK KK KKK KKK KKK KEKE KKK KEK KKK KEKE K KKK 


Mts function records the theoretical offered load 
for the entire network. Each node computes its 
load value and adds it to the global load variable. 
Mes function is called with the ENDSIM intrpt. 


RK kk ok ek kk kk kk kk kk kk kk kk kk kk kk kk kk kk kk kk kk kk ke / 


fa) 


mocorastheo load () 


{ 


Ere reecorad theo Toad ()) 
Sees ere GonattrTon makes Sure that the theoretical */ 


/* load value gets recorded once only and not by a 
/* every node zy 
me (finalgscalars written == OPC FALSE) 


{ 
Someta bee cake write ( Networks heemetuca | hoagea pines /cec) 
(double) nw_theo load) 
final scalars written = OPC TRUE; 
} 
FOUT 
ie end araneeron ~ / 


1A 
f 


f 


le ERR RIN ARIK te ck ke Re RR RR KH kK eR RR RK eR 


/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
v= 
/* 
/* 
/* 


BPupe Gilon - Seonvermumeadea |) Ca Mica errone EN ll saver 
InpuGs ; int arrayl[] = the array that will hold the converted data 
char array2[] = the string or character the user entered as a 
Simulation parameter 
parameter. 
Return: int = the number of data bits determined after parsing the user 
Input 
Purpose: This function is designed to accept a character string and convem= 
bhdsschawacter string into bit values, Dhe bituvaluecm, aimee 
returned in the the integer array. For example, if the user entered 
"'A' as the data_ bits simulation parm, then '1010' will be returned 
in the integer array. 
Assumptions: The user simulation parms are entered upper caSe. 
Last Mod: PTL r. Standrre Ldecomputer.ong 


+ 
“ 
“7 
Ta 
“e 
“A 
* 
7 
a 
<7 
= 
7 
Ty 
“7 
4 


DI TR ee eR ee eee eR ea ee A Re eA Re Ee 


eat 


Gonvert data(short arrayl[], char array2|[]) 


{ 


int Its 
PENGonveGe cacaishneort artrayll||, Char areay2iiy ) 


BOmiix-Oeecarraye !— "\O0'; ++array2Z) 
{ 
Switch (*array2) 
{ 
case 'OQ': 
amnay | axtt 4 
break; 
case 'l': 
arrayl[ix+tt] 
break; 
case ‘'2':; 
case '3': 
arbay [lL + } 
arrayl[ixt+] 
amma yi ix | 
if(*array2 == ' 
arGayl(ix++| = 0; 


Il 
© 


Il 
tr 
“se 


e Me 


ll 


{I 
INO hee 
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else 


arrayl[ixt+t+] = 
break; 
case '4':; 
ease ‘'5': 


arrayl[ixt+t] 
eb ea (ieee | 
aemayl | ixt | 
i1f(*array2 == 
array i [ix+) 
else 
arrayl[ixt+] = 
break; 

Gase '6': 

@ase ‘7's: 
aeray Wi) axt++ | 
array | lsc 
aba yl) | ix | 
if(*array2 == ' 

anray iii. | = 
else 

arrayl[ixtt+] = 
break; 

case '8': 

case '9'; 
arrayl [ixtt] 
apbayl|ix++] 
anray ii| txX++ | 
if(*array2 == ' 

arrayl[ixt++] = 
else 

airiayl [1xt+] = 
break; 

case ‘'A!;: 

case 'B': 
cmemavyl(ixt++] = 1 
arrayl[ixt++] = 0 
arrayl[ixt++] = 1 
1f(*array2 == 'A 

arrayl[ixt+] 
else 

arrayl[ixt+] = 
break; 

@ase ‘C': 

case 'D!: 
arrayl[ixt+] = 1 
aeray! [| extt] = 1 
arrayl[ixt++] = 0 
1f(*array2 == 'C 

array ie 1x4 | 
else 

dicted) | 1 x-f| 
break; 

case 'E!: 

case 'F': 
arrayl [ixt+t] 
arrayl[ixt+t] 


f 


0 

igs 

G; 
ae 


a 


II 
oo SS © 


=a Ne Ne 


1 
0 
0 
8 


dl 
s 
e 


-_—™ ™ ~ 
lf 


-_—™% ~ ~ 


) 


ji 
He 
“=e ™e 


no 


ewe ylipixt+} = 1; 

if (*array2 == ‘'E') 
aime ixt+|) = 0; 

else 
arrayl[ix+t++] 

break; 

default: 
break; 


ile; 


} 
} 


arrayl[ix} = -1; 


Beet Lx) 


INIT State 


/* get the objid of the generator process module */ 
Myotde-op id selt ()- 


Prtemjemera cd = 0; 

/* read the promoted attributes at run time x 
/* attribute DEBUG is included for debugging/printing purposes. aa 
fe) af TRUE, a bimen of printti statements throughout; «/ 
/* if FALSE, a much cleaner output * / 
Op ima Obj attr get(my id, "debug’, &debug) ; 

Somilageey altrager(my 1d, ) “Generatzon Rate", ~sgen rate); 
Cpeliiasobyeattr ger(my 1d, “user Gata bits”, Suse daca eajes)., 


/* convert the user data input (in hex) to array of short ints for data format */ 
user data bit length = convert_data(data array, user data bits); 


/* the following loop will set the pkt full of data bits. we assume the user ta 
/* entered some hex value, ie A, B, C, 1, 0, or whatever, as the intended data ‘bileauee 
/* the following will simply repeat this input value for the length of the 7% 
/* data pkt. The intent is to aid in debugging and keeping track of the data. bi 
/* By setting the data to a known value(s), we can give some quality assurance ba 
/* as we check the program throughout and check what comes out the other end. a 
/* The user just needs to enter the bit pattern of the application data. “i 
/* The coded bit pattern is repeated based on the user input bit stream at runtime a 
/* and the number DATA BITS as defined in mobile.h * / 


/* as well, we do this here rather than in the TRANSMIT state. It might hopefully save*/ 
/* us a little time. In the TRANSMIT state, we simply perform a block copy of these 7 


/* data bits over to a new allocated memory block, then insert the ptr pointing to gy 
/* that block (address) into the pkt. We have not determined if the block copy is any */ 
/* faster than the below loop, but one might suspect it certainly would be. a + 
/* nanosecond saved is a nanosecond earned maybe. The very last bit of data_array[] 7 
/* was set to -1 in the convert data() function. No big deal, as we are going to 7a 
/* overwrite it.now loop through the allocated array and cycle the user input bits a 
/* over the length of the array. sa 
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meee — 0, int ptr = data_array; int_ptr < data array + DATA. BITS? tint (pia ends 


mene ptr = data array(ix % user data bit length}; 


Jmeload the pkt generation distribution */ 

Meee ptr = op dist load ("constant", 1.0 / gen rate, 0.0); 
rand time = op dist_outcome(ia dist ptr); 

@ememerpt schedule self(op sim_time() + rand time ,0); 


TRANSMIT State 


@umeeprper = create data packet (data array); /* get a created data pkt and 


@eeeeea PkKptr != (Packet *) OPC NIL) /* check it to make sure it's good 
@empk send(data_ pkptr, UPLINK_STREAM) ; 

else 
errunts; #/* 1£ it's hosed, adjust our global counter. we! .esmeuma 


/* this global counter to keep track of pkt losses other 
/* than those from BER or PN collisions: 

J/* ideally, runts would == 0,. but it conld ascecunt econ 
/* aborted transmissions, power hits of the transmitter, 
/* gremlins in the network, whatever. 


/* in any case, calculate the random time for generating the next pkt so 
Meeeerme = op dist outcome(ia dist ptr); 


/* and schedule an intrpt for the delivery of the next pkt */ 
@umerpe Schedule self (op_sim_time () + rand_time, 0); 
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APPENDIX D. SLOTTED ALOHA SOURCE CODE 


OPNET CODE FOR SLOTTED ALOHA MAC 


Header Block 
Roger Standfield 
November 1997 


roger .standfield@mctssa.usmec.mil 





mrnclude <math.h> 
merelude "“"mobile.h" 


#define SUB QO 0 
#define TX PACKET 0 
#defineTO PHYSICAL LAYER 0 
#defineMIL 1E6 


Mm wconditional macros */ 


#define PKT ARVL (op. intrpt type {) == ORC INTRETAOERM) 
#define 0 EMPTY (op subq empty(SUB Q)) 
#define ENDSIM INTRPT (op intrpt_type() == OPC_INTRPT ENDSIM) 
#define BEG SLOT ((op_intrpt_type() == OPC_INTRPT SELF) && 

a (op Inerpt code() == TAgrseknl 
B= **** Global Variables REA i 
extern int debug; /* the three extern vars are defined in */ 
extern int runes; /* in the conversation model process 7 
extern Stathandle Pits State aeame le, 
nt total slotted arrivals; 
nt meeal slotted” meceareukes, /* how many make it thru the Q */ 
double slot _length; /* the time occupied by our bits */ 
Boolean final slotted_stats_written = OPC_FALSE; 
Boolean INIT info written aeOle, FALSE: 


Stathandle slotted_ arrivals PHancre, 
Stathandle slotted _departures_ handle; 


meee Function Declarations *****/ 

void eeimt the pkt (Packet* pkptr); 

void record slotted stats(); 

Backet* create mac_pkt (short header bits array (i); 
Packet* add data to mac_header (Packet *heademepkpel racket dared, eae km ei 


State Variables 


int \packet_ length; 

ent Nemes Sele, 

ont \guard_ band; 

short \mac header bits array[MAC_ BITS]; 
double \eni pe RATE; 
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Ob) id \my_1d; 

Boolean \mac pkt sent; 

Plariamale  \chan accessylocal handle; 
Stathandle \chan_access_ global handle; 


Temporary Variables 


Shore “data bit pty tarareen, 
double chan access iaetay, 
Paget aata pkptr, 

Packet *mac_header pkptr; 

Eoehoea mac pPkKptr; 

eouOlemw PkKercreation time = 0.0; 


: Function Block 


KERR KKK REE RK REA RAE ERREARKREEEKEE EXER K KERR KE ERE & eR eee 


this function is designed to print out the contents of a packet. *Packet is 
passed in. Check each field=bit of the packet, and print out the packet as 

aqesctt igor 1's ande0's:. 

EE RRR PK RRR EER ER RE RR KR EEE RE A ee Re eK RE Re Ee eee 

Pole p ant. Une ke VPacket “pkpirr) 


{ 
ieee cata olu oli Length cOra es lZc mous ze. 


PPM Ori nt eo kixpkptr) ) 

totale size — sop) pk EOtal size get (pkptr) ; 

uikecize — Tomepk bulk si zeugeripkpcr); 

Bae bengen — bulk isize == eeeCeal 51 ze 78 eCtal (Size) sou lceedze. 


/* loop through each bit of the packet (excluding any bulk size field, which ai! 
J* 12S not accessible on a bit basis), extract the bit, and print 22 1ome ~/ 


fhe miex—O; ix — bit length, ++i) 
{ 


Di(op pk fd get(pkptr, ix, &data_ bit) == OPC COMPCODERSUccl. 
Petmet( sd", datarbit); “ 
else 


{ 
op sim _ message("INSIDE PRINT THE PKT FNCT. COULD NOT GET THE FIELD FROMSE Ta ae 
break; 
} 
} 
iste. \n )G 
BOUT 


meee xk kkk kK KR KR KKK KR KKK KERR EK KKH RK KKK KKK KK RX WRK EK KRA A SARK AK 


ae Punction: create Mache a7 
fe Inputs: None A 
y~ Return: Packet*= A newly created pkt of format = MAC PKT | ?he daddies] aoe ae 
* MAC HEADER bits is placed inside the pkt as a structure field. oy 
P~ Purpose: This function is designed to add a medium access control (MAC) ayy 
,* segment to a packet. This function creates a new packet, loads the first wi 
Sa N bytes of this new packet with 1's, then copies over the bits of the yi 
y* received packet into this new packet. N = a user definable simulation * / 
a parameter defaulted to 5 (bytes). The received data packet is destroyed */ 
a Pichi aeeriis LUNCt LOM. * / 
e* Last Mod: 10/97, r.standfield@computer.org * / 


eee KARA RRA AAA HAA AKA aEEREK KKK RAK HERA RE KEE Re ee ee 


Packet* create mac pkt(short header bits array[]}) 


{ 


Eacket* mac _ header pkptr; 


Snort *mac header bits_ ptr; 
Boolean NAG ue emer cat Cece eOPCerALSE, /* guilty until@proven annecenem. 
mac header pkptr = op pk_ create fmt ("MAC PKT"); /* create our new packet */ 
ge{mac header pkptr != (Packet *) OPC _NIL) /* lf Ole continue ay 
{ 
/* allocate the memory for enough mac header bits. MAC BITS is defined in mobile.h 
mac header bits ptr = (short *) op_prg_mem_alloc(MAC BITS*sizeof (short) ); 
maeleemneader bits ptr != (short *) OPC NIL) 


{ 


faeecopy Over Our maceWheader bits array into this address reserved just fomsuse 
@enprg mem copy(header bits array, mac header bits ptr, MAC BITS*sizeort(shore |), 


/* now need to put the memory address into the pkt. */ 
if(op pk nfd set (mac_header_pkptr, "MAC HEADER”, mac_header bits ptr, 
Op prg Mem copy create, Op prg mem Ereéc MAC BIS sizecm(shome saa 


OPC COMPCODE SUCCESS) 


Mac epkt created = OPC TRUE; 


else /* else we failed to set the address in the pkt; clean up ay 


{ 


Oop prg mem free(mac_header bits ptr); /* pkptr & memory ok, but failed to put*/ 


op pk destroy(mac_header pkptr); /* address into pktveireesup been 
op sim message("ERROR:create mac pkt():\nFailed to SET mac header 
- 7 addmess im eke 4 
"Allocated memory is released, MAC pkt destroyed."); 
} 
} 
else 


{ 


op pk destroy(mac_header pkptr); /* pkptr was ok, but no memory for header bits */ 


op _sim_message("ERROR: create _mac_pkt():\nFailed to Allocate memory 
for header bits", 
"MAC Pkt destroyed."); 


} 


if(mac_pkt created) 
Geturn(mac header pkptr); 
else 


{ 
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emote ssage: ERROR: create mac pkt()", "Failed to Create pkt of MAC UPACGKE 


fOMMiate ai, 
Boman (Packet: ~*~), OPC NIL); /* if we couldn't get a pkt, return a null pig 
} 


ye endW@ereate mac pkt(jm*/ 


Packet*add_ data_to mac header (Packet “header PKpEr, weaecer *datal packe uawiea: 
= 
Sota catawolrs pur, *header bits ptr; 

Soub lew KE. creation_ time; 

Boolean data meies _added ae ewe), /* we're always guilty aren't we? */ 


if(op_pk_nfd_get(data_packet_ptr, "DATA", &data_bits_ ptr)==-OPC _COMPCODE SUGGESs) 
ae 


if(op pk _nfd_set (header _pkptr, "DATA", data_bits ptr, op prog mem Copy creaeee 
op prg mem_free, (DATA_BITS*sizeof(short))) == OPC COMPCODE SUC@Hees 
i 


data bits added = OPC TRUE; 


/* we attempt to monitor the ETE of the original pkt. we'll pass one 
/* the info here. not a show stopper if it fails, just loss of some 7 
/* statistical data. * / 


if(op pk nfd get (data_packet ptr, “creation_time”, é&pkt) creaticn eime™ 
{ 


Pi meee ed seu (header ipmpek. “ekcat lonmitme pkt_ creation Serpe 
Opesimemessage | ERROR Rar iC GENERATOR: add _ Aas _to_mac _header()" 
"Failed to transfer Original “PKT Creation Time. 


ELE data may be bogus”); 
} 


op pk destroy (data_packet_ptr); /* the bits have been 'copied’ over: bi? 


/* no further need @ier this ace xy 

} 
else /* else we failed to set the data bits address in the */ 
jomOkuasclLean up +7 

{ 
op prg mem free(data_bits ptr); /* ptr is good or we wouldn't be */ 
/* in this sbranen “7, 
Semekedestroy (data packet ptr); /* we assume the pkptr passed in */ 
/* was good x7] 


@p sim message ("ERROR:add data to_mac header ():Falledwioscen 
data bits address in MAC pkt!", 
"Allocated memory released, Data Pkt destroyed."); 
} 
} 


else /* else we failed to retrieve the memory address */ 


/* of the data bits. destroy the data pkt ny 
{ 
Smo mcdeseroy(data packet prr); /* again, we assume the pkptr passed */ 
/* in was good x7] 


SemolMemoessage( ERROR: add data to mac header(): Failed EO GEL 
data bits address from data pkt!", 
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} 


i * 
/* 
a 
/* 
/* 
/* 
/* 
ve 
yx 
/* 
y* 
/* 
jf * 


"Data Pkt destroyed. Allocated memory for DATA BITS is not released."); 


if we were successful above, then we have added the pointer to the data bits 


into our MAC pkt and destroyed the data packet that brought us the data bits. 


If we had a problem we dealt with it, releasing the memory that we could get 


a pointer to, and destroyingthe data packet afterwards. Although the data pkt 


has been destroyed at this point, we ensure we do not deallocate the memory 
where the actual data bits reside, unless of course we had a problem above, 

as mentioned. Lastly, we'll check on the results of above and if successful, 
we'll return the header pkptr that was passed in as it now has the data bits 


added to that pkt. If we were not successful in adding the data bits, the MAC 


header pkt is of no use. We'll release the memory, if we can, of the MAG 
header bits, destroy the pkt that was passed as it serves no purpose, then 
mi@ally return a null ptr indicating the operation add data to mac headen() 
was a flop. 


if(data bits added) /* if we successfully encapsulated the data bits, 


else /* else without the data bits encapsulated, the pkt is junk. 


{ 


woid 


/* we're golden 
meeuen(header pkptr); /* return the passed in pkptr, with the added 
/* data bits address 


if(op pk nfd_get(header pkptr, "MAC HEADER", &header bits ptr) == 
OPEC COMPe UDEV SUCEE os) 

op prg mem free(header bits ptr); 
else 

op sim message("ERROR:add data_to mac _header:Failed to GET 

ae MAC Header bits address from MAC pkt!", 
MMBC Pkt destroyvea Allocated Memory) or MAG aeke 
is not released."); 


/* regardless of deallocating the memory taken by the mac header bits, we'll 
/* destroy the pkt 
Sememecaestroy(header pkptr); 


iemm@em’ (Packet *) OPC NIL); /* and return a null pkptr */ 


meeora slotted stats () 


{ 


double normalized load, normalized_mac_thruput; 


“i 
a 
aes 
7, 
ee 
oy 
ay! 
me 
es 
taf 
a7) 
= 
Ta, 


i 
he 
a 
7 


ot 


ane 
ay 


double channel capacity = NUMBER PN CODES / slot length; 
/* channel capacity is determined as the number of unique PN sequences * pkts/sec, */ 
/* equating to K*pkts/sec. NUMBER PN CODES is defined in mobile.h. We can receive ney 
J/* one pkt per slot, thus our capacity is as shown above. ro 
me(seinal slotted stats written) 
{ 
Oop’sim message ("SLOTTED2:RECORED SLOTTED STATS().", "Writing Final Slotted Stats"); 
normalized load =" total slowed arrivals / {op_sim_time()*channel capacity); 
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PeimaleZeq mac thruput = total siketted departures / 
(op_sim_time()*channel capacity) ; 


eee e omc co hag wirile(  Lotal Slotted Arrivals” 
en sbaee Becalar write ("Total Slotted Departs " 
op stat Bscalarewrite ("Normalized Load ‘s 
op stat scalar write("Normalized MAC VT haupDut 
Pines Omeedestdesuwrittem — marc TRUE, 


; total slotted arrivals) ; 

; ota _slotted_ _ departures): 
; normalized load); 

; normalized mac thruputyy 


INIT State 


/* who am i anyways? */ 
Myo oped scli(); 


/* initialize variables and set the MAC HEADER BITS to some values */ 
total slotted arrivals On 


total sorted — Pecos ieuise Ss ee. 
mac_pkt_sent = OPC FALSE; 
/* set all the mac header bits == some value, we'll use all 1s fer me, 7 


for(int_ptr = mac_ header bits array; int_ptr < mac_header bits array + MAC BITS )+siigeeee 
SAMs ie ee 7 


/* get the promoted attributes at run time */ 


Op ima obj attr get (my id, Us LormLengteh, (¢shouwlengireh)y; 

op_ima_ obj attr _get(my_id, "CHIP RATE", SCHIP RATER 

Soe MaPoOe matt Eeger (my ta, "guard band", é&guard band); 

/* determine if the user input any value for slot _ length. Default value is 0.0; ‘a 
/* The slot length is determined as pkt_ length / (chip _ rate / k) where a 
/* k = pn sequence length. If the user has input different values, run the <7 
/* simulation based on those values * / 


becker mlength =o (SYNC BITS*SYNC Bits FG) + (MAC Bits (palate sa 
8*guard_ band) *DATA BITSmEGe 


if(slot_length == 0.0) 
slot length = £floor(((double) packet length / CHIP RATE) * (Miia = ae, 
/* round it off to usecsmaa 


Pan ET santo written) 

{ 
@pustde scalar write("“Pkt Length”, (double) pacver erences. 
Cesta e Beco ear _write ("Slot Benge , SloOeerengti):, 
INIT info written ene mya) 

} 


/* get the statistics handles */ 


chaneeaeccess local handle = op stat reg( "Chan Access Delay imsec 
OPC_STAT_ INDEX NONE, OPC_STAT_LOCAL) ; 
enanmeccess global. handle = Op _ Sea _reg ("Chan “Access Delay (msec)" 


OPC STAT INDEX NONE, OPC_STAT GLOBAL) ; 
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Beorted arrivals handle = op stat reg("Total Slotted Arrivals”, 


OPC_STAT INDEX NONE, OPC STAT GLOBAL) ; 


slotted departures handle = op stat reg("Total Slotted Departures", 


OPC STAT INDEX NONE, OPC STAT GLOBAL) ; 


mm Schedule a self intrpt for the first time slot a 
Memntrpt schedule self(op sim time () + Slot length, “lasrACkn ir =, 


QUEUING State 


J* get the packet from the strm. */ 
Gata pkptr = op_pk_get(op_intrpt_strm()); 


m insert in q. */ 
op subq pk insert (SUB Q, data_pkptr, OPC_QPOS_TAIL); 


Meeanning Count of pkts offered to the MAC, essentially the Load! */ 
Semeotaeewrite(slotted arrivals handle, ++total slotted _arrivals); 


TRANSMIT State 


7 * 


If the Q is !empty, remove the packet from the Queue, add a Header, */ 
/* and collect some stats, then send the pkt to the outstream. * / 


meee pkt sent = OPC FALSE; 


Be(Op subq empty(SUB_Q) == OPC_FALSE) 


{ 


data pkptr = op_subq pk_remove (SUB Q, OPC_QPOS_ HEAD) ; 


ae 
/* 
/* 
/* 
/* 


ao 
/* 
/* 
/* 
y* 
aX 
/* 
a 
/* 
yx 
/* 
y* 
7 * 
/* 
/* 


ereate mac pkt() will create a new pkt of format MAC PACKET. In that function, 
we'll request a memory allocation for storage of the MAC Header bits. We add the 
MAC Header there, which consists of all 1's of user definable length, as set in 
mobile.h. The pointer to this memory location is added as a structure to the 

MAC PACKET. 


add data to mac header() will attempt to retrieve the memory ptr to the data bits 
and add this pointer to the MAC PACKET. If successful, the data pkt is destroyed. 
If unsuccessful, the memory allocated for the data bits is released if possible, 
The data pkt is still destroyed, regardless of releasing the data bits memory. 
Also, if unsuccessful, the memory allocated for the mac header bits is released 
if possible, and regardless, the MAC PKT that was created is destroyed. The end 
result is: if the data bits were successfully encapsulated within the MAC PACKET 
we get the packet pointer we sent it, containing the added data bits. If it went 
bad, the function will clean up as much of the mess as it can, and returns a NULL 
Packet pointer, flagging us that there were problems. If all went well, send the 
fully formatted and encapsulated pkt on its way. If not, chock this one up to 
gremlins in the network, and ajust our counters. We don't count this type of loss 
as a pkt loss, as are pkt losses are defined as pkts failing to reach sync in the 
receiver due to: 1) BER's from the channel, or 2) PN Code collisions. Thus we 
keep a gremlin count of miscellaneous pkt losses, and refer to them as ‘runts’. 


a 
ay, 
a 
ah 
ty 


ae 
7 
a7. 
a 
7 
a 
ooh 
a 
ay 
a 
eA 
may 
a7 
a: 
oh 


PaemeeeagenepkeEr — Create mac pkt(mac header bits array); 
1f(mac_ header pkptr != (Packet *) OPC NIL) 
{ 
iaeeotelme—wacdd data to mac header (mac header pkptr,data pkptr)- 
Vm@iaceesper st— (Packet *) OPC NIL) 
{ 
Seep senaimMac Pkptr, TOLENYSICAL LAYER); 
iacmectescenius— OPC TRUE, 
op stat_write(slotted departures handle, ++ttotal slotted departures) ; 
} 
} 


Pea iniee okt Sent) 


ite e S > 
} 
/* Regardless of the Q being empty or not, schedule a self intrpt for the next ae 
/erimes Slot a 


GeEI MET PE schedule selt (op Sim time() + slotelength, 1x geaeran): 
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APPENDIX E. PN SPREADER SOURCE CODE 


OPNET CODE FOR PN DESPREADER 


Header Block 
Roger Standfield 
November 1997 


roger .standfield@mctssa.usme.mil 





mrnclude <math.h> 
fanclude "mobile.h" 


#define OVER THE AIRWAVES 0 
#define MAC STREAM 0 
( 
( 


moctine MAC ARRIVAL Op _Intrpe type() —— OPC INTRES Saharan 
op intrpt_strm() == MAC STREAM) 
m*** Global Variables roe 
extern int debug; 
mxtern int COnvecummeadtaysiore arrayl|), char array2{ |} 
extern void Pete an aemay (char “Ghar string, “shore ant ee aap eeccmeernyee 
extern int munts: 


m*** Function Delcarations ***/ 


eee spread the pkt(short pn sequence array[], short sync bits_array([], Packet 
*data_pkptr); 
void generate pn code(short pn_code[],short polynomial array[], short 


shift _register[]) 
void Perec right(short array([]) 


void Semvert poly(char earae short array2[]) 

ert Char to int(char char in); 

Benort get_ feedback(short feedback polynomial arrayi], Shove reqrsre mya ca ian, 

Packet* create spreaded packet (short *pon code bit ptr, short *syne DLEY ptr, skachor 
*pkptr); 


Seer allocate me lots of memory(); 

Meort~ find mac header bits in(Packet *pkptr); 

Meeee tind data bits in(Packet *pkptr); 

void feeead sync bits(short *spreaded bits ptr, short “syne bit ptr, 
Short “pa, code gos acini: 


wold feeead mac header bits(short *spreaded_ DIESepuL, short *mac LOSES! Per, 
SHORE. pmsodero tenor. ), 
void Bp-ead data bits (short *spreaded bits ptr, short *data bit ptr, 


ShOTE, 7 BN eOde loi pin): 
Boolean encapsulate spreaded_ bits_with(Packet *pkptr, short *bit ptr); 
void Peee Up the memory. from(short *mem _hogl ptr, short *mem Negq2 per, Packer. phoran 
void transfer data pkt creation_time (Packet ‘old pkptey, Packel “new lpi. )e, 
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State Variables 


/* the debugging phase of this model pointed out how painfully aware we must 


/* be of memory management. notice most, if not all, of the structures aresmcune 
/* short ints. Not all are necessary, and in some cases, little is saved. But, 
/* to keep it all simple and a little less confusing, we've tried to standardize 


/* on keeping most everything as short. it hopefully reduced the number of 
/* undiscovered bugs. 


char \user input register _load{REGISTER_BIT LENGTH + 1]; 


char \polynomial [3*REGISTER_ Bil LenGuni, ‘/* we can afford a little extra room 


short \shift register polynomial array{REGISTER BIT LENGTH+1] ; 
Jo REGISTER SEH) SEENG any SYNC Bris, 


/* DATA BITS, etc are defined in mobile.h 


Si@memeolEtt TegGister array (REGISTER Bit sLENGTH + 1); 
short \sync bit array{SYNC BITS]; 

short \pn_code _array[PN_ CODE LENGTH] ; 

Objid \my id; 


Temporary Variables 


sete a 
Packet *mac pkptr; 
Packet *spreaded data pkptr; 


Function Block 


Packet* create spreaded packet(short *pn_code bit ptr, short *sync bit ptr, 
7 = Eacker a data mp ati) ~ . 
{ 
aaa MAC SBETS OFFSET, DATA BITS OFFSET; 
short *mac header SDIES Oe, *spreaded_ data bits ptr; 
sowie data bits ptr, *int ptr; 
Packet *spreaded _ pKOEL- 
Boolean weer off _to_a good start, mission_accomplished; 


Meee rT SO OFFSET 
DATA _ Bers BOPFSET 


SINC  Bigks*SiNC Bi TS EG, 
MACS BITS _OFFSET sf MAC __ BITS* BaTA BITS PG, 


spreaded_ pkptr = op pk create_fmt ("SPREADED PKT") ; 
aeseaded data bits ptr = allocate Menlots or menen, a. 
Vector PO a _good_ start = (Boolean) spreaded pkptr && (Boolean) 


spreaded data bitsuprm 


yr 
i 
ay 
7 
a 
+o 


+7 


| 
a 


iweer Off to a good start) 


{ 


mac header bits ptr = find mac header bits 4 daeae ae ean 
meqmacaheader bits ptr b= (short *) OPC _NIL) 
{ 


Bata ES spl = find data bitseim datarpie aa. 
if (data_ DEES IDEr l= {(snort..*).OPRG Nik 
{ 
iis pts — Sspreaded data bits ptr, 
peicedssyne bites (int foc Sync Dit pir, povesdeeaesptim 
spread mac _header anes {ene Ober 7 Meee bis _OFFSET, mac header t bits soe a, 
pn_code bit ptr); 
Beread data bits(int ptr + DATA BITS OFFSET, data bits ptr, poy code somessee 
transfer data pkt_creation_time(data_pkptr, spreaded pkptr); ra 
free up the memory_ from(data bits ptr, mac Neader Dits per, datamekper 
mission accomplished = 
encapsulate spreaded_ bits with(spreaded pkptr,spreaded data bits ptr); 
te{!mission accomplished) = — _ 
{ 
Seeprg Meter rscee |[Spreaded data bits ptr), 
op pk_ destroy (spreaded_ SkpEn: 
ees im message ( ERROR SPREADER: create Spreaded packer, | 
7 UEP kelose tO Oremlins. Wiss 


} 
} 
else 
{ 
op sim message ("ERROR: PN SPREADER: create_spreaded_packet (); 
"Memory Allocation for Spreaded Bits Failed!"); 
} 
B-eeemopreaded Pkptr) ; 
} 


wold 
@ransfter data pkt creation _time(Packet *old_pkptr, Packet *new _pkptr) 
{ 
double pkt_creation_time; 
Boolean xfer S(O 210, sleeps yal 6 
Boolean both pkts are legit= ((Boolean) (old_pkptr) && (Boolean) (new_pkptr) ); 


/* the original pkt creation time has hopefully been passed along, as this ua): 
/* pkt has undergone several face lifts. We'll attempt to keep passing a 
m along the info.*/ 


me (both pkts are legit) 
Seo pK nfd _get(old -PKpte,. Grcation Lime! se cekewenede toms ries 
@irop pk nid set (new_pkptr, "Creation time", pkE creation eime 
xfer = OPC TRUE; 


if(!xfer) 
op sim message ("SPREADER: transfer data creation _time(). Null pkts passed in??, go 
PLOULe a, 
"Failed to xfer original pkt creation time. ETE data will be bogus"); 
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} 


meturn ; 


void 
PecemUemencememory from{short “mem_hogl ptr, short *mem_hog2 ptr, Packet ae memem 


{ 


Cememen mem tree(mem hog! ptr); 
op prg mem _free(mem_ hog2 pes); 
op pk destroy(pkptr); 

return; 


Boolean encapsulate spreaded bits with({Packet “pkptr,, Sh@mem soit sci 


{ 


Bee lLeamopreadcdyoltsS address 1s Set = Clem aeog, /* need to prove this wrong */ 


/* printf("PN SPREADER: encapsulate spreaded bits().\n"); 


ee 
if (op_pk_nfd_set(pkptr,"SPREADED DATA",bit_ptr,op_prg_mem copy create, 
op prg_ mem free, SPREADED _LENGTH*sizeof (short) ) == OPC COMPCODE SUGGES s 
spreaded bits address is set = OPC_TRUE; 


else 
op sim message ("ERROR: PN SPREADER: encapsulate uspreadedsbibsiwit pia 


"Failed to insert spreaded bit ptr address into pkt!"); 


Bort aoe so iaccmen eo macdcdross —Smsct), 


Vomdyspread data bits (short “spreaded_ bits ptr, short *datalbrtr per momems 
eae coce Dit ptr) 


{ 


SOc I Ne Ptoly, “int ptrdZ; 
Sion CULeGE loop Upper bound = data Diteerr 7 DATA IBIS, 
short *inner loop upper bound = pn_ code CEG aOe © ot DATA __ BITS (EG; 


fom(ant prrl = data bit ptr; int _ptrl < outer loop upper bound, 7 ata. eam 


{ 
2£(*int ptrl == 0) 
{ 


for(int_ptr2 = pn_code bit ptr; int_ptr2 < inner loop upper bound; ++in Gage 
*spreaded bits ptrt+ = *int ptm@e-— 0? -1: i; 
} 


else 


{ 
for(int_ptr2 = pn_code_bit_ptr; int_ptr2 < inner_loop_upper bound; ++inuajggeee 


*spreaded bits ptrt++ = *int per2 == O02 Toad, 
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eid spread mac header bits(short *spreaded_ bits ptr, shore “maceb tts spre ene 
men code bit ptr) 
{ 

Semi *int ptrl,  *1nt perZ, 

Paome. “Outer loop upper bound = mac bits pers: Mecebii 

ice. “inner loop Upper bound = pn code bit ptr + BATAgET cere, 


Beaeme ptrl = mac bits ptr; int _ptrl < outer loop upper bound; tone ere) 
, Meaieint ptrl == 0) 
Gemeint ptr2 = pnecode bitaptr; int ptr2 < inner loop uppéreseund, +finceper | 
maereaded bits OErt+ = "ane ptr2)—— G2 [il 
ae 


{ 


Seaikeeptr2 = pn code bit ptr; int _ptr2 < inner loop upper bound? 2 ine 
mee ecadede bh Lis ort teSine ptr == Ui. =i, 


Sete@eemeaad Sync bits(short *spreaded_ bits ptr, short *sync bit ptr, short 
mon code bit ptr) 
{ 

Mie@eeeeint ptrl, *int ptr2; 

SiomemmmeouLcr loop upper bound = sync bit ptr TPaorNc. BITS, 

Fiemme inner loop upper bound = pn_code bit ptr + SYNC BETS PG; 


Peetimemptrl — sync bit ptr; int _ptrl < outer loop upper bound; ++int ptrtl) 
; Peet ptrl ==—0) 
| Pemiint ptr2 = pn_code bit ptr; int_ptr2 < inner loop_upper bound; +*+int ptmm 
foe Jdeemot homer = int plr2 —-— O07 i. i, 
ae 


{ 
Meeent ptr2 = pm code bit ptr; int _ptr2 < inner loop upper bound; ++int perZ) 


*spreaded bits ptrt+ = *int_ptr2 == 0? 1: -1; 
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Si aeeeticweata bits in(Packet *pkptr) 
{ 


short piaemec Ilo beOoLes per ,— data obits ptr = (shore ~) OPC Nin: 


PMCpepk mtd get (pkptr, "DATA", &data bats ptr) == ORG COMPCOPE EATEDEG, 
{ 


if{op_pk_nfd_get(pkptr, "MAC HEADER", &mac_header_bits ptr) == OPC COMPCODE FAIMiaias 
{ 
Cwoupe Gestroy (pkptr), 
op sim message ("PN SPREADER:find data bits _in():Failed to retrieve 
ae = MAC & DATA bats ptn”, 
"UNABLE to Deallocate MAC BITS + DATASBI Tema ces 
(Short) er memory!) 7 


} 


else 
{ 
op _prg mem _free(mac_header bits ptr); 
Open destroy (pkKpEn), 
op sim message ("PN SPREADER: find data bits in():Failed to retrieve 
aa Bysdba. ouMetsmysicve use 


"UNABLE to Deallocate DATA BITS bytes (short) of memory!!"); 


} 
} 


return(data bits ptr); /* it was either set to some legit value, or is still OPG@iie 
cs 


short* find mac header bits _in({Paeket™*pkptr) 
{ 


ShObEs “datarbits plLr, “mac headereolts per — (shorty) see wee, 


if(op pk _nfd_get(pkptr, “MAC HEADER", &mac_header bits ptr) == OPC COMPCODE FAERIE 
{ 


Pe Comet rea cel (okpinr, "DATA", Sclatea OES ames) == OPC COMPCODE SATE 

{ 

Op phecestroy (pKptr):, 

op sim message ("PN SPREADER: find mac header bles agate becca. 
retrieve MAC & DATA bits ptr", 


"UNABLE to Deallocate MAC BITS" + DATASET lose e_- 
(short) of memory! !"); 


} 
else 
{ 
Spepegamem Emee(data Dits ptr); 
Gp pk destroy (pkptr) ; 
op sim message ("PN SPREADER: find mac header bits je Fa rleciae 
- oa retrieve MAC bits ptr", 


"UNABLE to Deallocate MAC BITS bytes (short) of memory same 


} 
} 


return(mac header bits ptr); /* it was either set to some legit value, or 1s)S em 
SE CaN ii */ 


} 
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Eaort* allocate me lots of memory) 
{ 
Sere *Dig block memory per, 


big block memory ptr = (short *) op _prg_ mem alloc(SPREADED LENGTH“ sizgeon(shom aa. 
memurn (big block memory ptr); /* this ptr is Gither legit cr = —s0r ener 

} , 

void 

Zemerate pn code(short pn_code{]j,short polynomial array[], short shift register{]) 


{ 
ee, JX, Nn, max length; 
short feedback; 


Peiigemerate pn code(short pn_code[],short polynomial array{], short shift regqister(|))) 


n eee eGlolTER Bil LENGTHA; 
teemrength = PN CODE LENGTH; 


Pome — O; ix < max length; ++1x) 
{ 
Bemeoce{ix] = ShHitepreg eter {n—1]; 
feedback = get feedback(polynomial array, shift_register) ; 
Siemeemr i ght (shift register); 
Shift register[{0] = feedback; 
} 


BOUL 


void 
Satie right(short array[])) 
{ 


dein ix | 

Pei@emett right(short array[])) 

Meme REGISTER BIT LENGTH-1; ix > 0; --1x) 
array[1ix] = array[ix-1]; 


array[{0O] = 0; 


FOUT 
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omc omvereEmDoly(enar arrayl[j], short array2[}) 


{ 


iis dex = (0; 
iter rayl = oR £6 *(arraylt+1) != *4' 
SPeotmeneen bErOr On opreading Polynomial Value! %, 
“Cannot, Determine Polynomial”, “Exiting Simulation 31 .9P 
else 
{ 
arrayl += 2; /* skip past the 'R(' chars of the inoue 
for(; *arrayl != '\0O'; ++arrayl) /* until we hit the ending null char eee 
{ 
if(*arrayl != ',' && *arrayl != ')' && *arrayi != " ') /* skip commas, Spaces 
/* and the closinguyam 
amgeaycuixt+| = char to. int (*arrayil— i), /* our arrays vous 


/* indexed at zero! 
} 
om eel — REG ioe RSET LENGTH: tax) 
array2(ix] = -1; /* £111 to the end of our array with -l's 


} 


Ferturm: 


} 


Shie@emehae ero lnit char. Char i711) 


{ 


short temp; 
Switch(char_ in) 
{ 

Gasser Ue: 
temp = 0; 
break; 

case 'l': 
temp = 1; 
break; 

Case. 22 
temp = 2; 
break; 

case '3!: 
temp = 3; 
break; 

case '4': 
temp = 4; 
break; 

case '5': 
temp = 5; 
break; 

case '6': 
temp = 6; 
break; 

ease '/': 
temp = 7; 
break; 

case '8':; 
temp = 8; 
break; 

case '9'; 
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temp = 9; 

break; 
default: 

break; 


} 


return (temp); 
} 
short get feedback(short feedback _polynomial_array[], short register array[]) 
{ 
abn nex ; 
Pit@ee Ones count = 0; 


for(ix = 0; feedback polynomial _array[1ix] >= 0; ++1x) 
ones count += register array[feedback_ polynomial array[ix]]; 


Beemrmones count % 2); 


INIT State 


/* get this process module's own object id */ 
my 1d = op id self (); 


/* get the simulation input parameters */ 

op ima _obj_ attr _get(my id, "user register load", é&user_ input register load); 
op_ima_obj attr _get(my_ id, "polynomial", &polynomial) ; 

Benvert data(shift register array, user _input_register load); 

convert poly(polynomial, shift register polynomial array); 


Memee NewETITS is defined in mobile.h. It represents the number of sync bits that will */ 
Meepretace the application pkt. The function, spread the pkt() will combine the sync */ 


m bats with the received mac _ pkt from the application layer, then spread this dg 
/* according to the generated pn code. The sync bits are not the primary focus of oy, 
/* this work, thus we merely define in mobile.h the number of sync bits, and define a7 
/* them to be all 1's. Bf 
eee, 1x < SYNC BITS; ++1x) 
Sy@emete array[ix] = 1; 

/* to implement the pn sequence business, we'll create an array which will hold our of 
/* generated pn sequence. Send this array, the polynomial, and the register array to */ 
/* the function. upon return, the pn _ code array will contain the generated pn a) 
/* sequence. 2a), 


Menerate pn code(pn code array, shift_register_ polynomial array, shift _register array); 


/* SPREADING State */ 
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SPREADING State 


/* retrieve the incoming data pkt, which we'll refer to as the mac pkt +7 


Neem tee — Oerek gee (op intripe strm ()); 


/* now pass in our generated pn_code_array, our sync bit array, and our mac pkt +7 
eG spread the data(). spread the data() will extract our mac header bits, our */ 
/* data bits, and will combine these with our sync bits into an array. Next it * / 
/* will spread all of these bits according to the pn sequence in pn code array. 7 
/* This spreaded bit stream is maintained in memory, and the pointer to it is <7, 
/* placed in our spreaded pkt. The ptrto this spreaded pkt is returned from x 
/* spread the pkt(). * / 
spreaded_data_pkptr = create_spreaded_ packet (pn_code_array,sync bit_array,mac_ pkptr); 
/* We have taken our data bits and our mac header bits and spread them into “7 
/* our spreaded spreaded pkt. The memory space allocated for these bit streams 7 
/* (allocated in our traffic generator and our slotted process) was deallocated 7 
/* in spread the pkt(). mac_pkptr, the pktptr that brought those (pointers to) se 
/* data and mac headér bits was also destroyed in im spreadeente data “a 
/* before sending, ensure we set the pkt size to the proper value. as this is a */ 
/* formatted pkt of format "SPREADED PKT", and the value of the one and only “7 
/* field 'SPREADED DATA' is set as a structure, we effectively don't have any A 
/* pkt size. Thus, we'll have to set it here as the pipeline stages will query +7 
Je wos value. */ 


if(spreaded data pkptr) 
{ 
Cen ecealstze Set (Spreaded data pkptn, SPREADER LENGE: 


/* send the pkt out the outstream ee 

ep pk send(spreaded data pkptr, OVER THE AIRWAVES); 
} 
else 

tet le Sap 
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APPENDIX F. PN DESPREADER SOURCE CODE 


= OPNET CODE FOR PN DESPREADER 


Header Block 
Roger Standfield 
November 1997 


roger .standfield@mctssa.usmc.mil 





mimclude <math.h> 
fenclude "mobile.h"™ 


@ectineSYNC ACHIEVED 
#defineTO HIGHER LAYER 
#defineNEW ARRIVAL 
#defineADD ONE 
#defineGOOD PACKET 
#define PN COLLISION 
#define VOICE DROP 
#defineRUNT PACKET 
#defineSYNC_ FAILURES 
#defineETE DELAY 
#define INFO BIT ERROR 


oOo oO OS® WNFHFH OOF 


#defineMAXIMUM VOICE DELAY .040 
#define TAU SOoe 
medeftinitions for our state transitions a 
#definePKT RECEIVED (op intrpt_type() == OPC_INTRPT STRM) 
#defineACHIEVED SYNC (op _intrpt_type() == OPC_INTRPT SELF && 

7 op intrpt code() == SYNC ACHIEVED) 
#adefineEND SIM [op intrpt type() == OPC _INTRPT ENDSIM) 
me struct Ele oEQUENCE is defined to hold a particular PN sequence, Ay 
/* which we will generate many of in our INIT State. */ 
/* matrix of pn sequences [NUMBER _ PN CODES] [PN CODE LENGTH] is defined to a, 
/* store a pn sequence for every ‘'m' sequence of each defined PN ay 
Mm characteristic polynomial. */ 


typedefstruct 
{ 
short bit _array[PN_CODE_ LENGTH]; 
} PN SEQUENCE; 


me * Global Variables op 

extern int debug; /* simulation parm used for levels of debugging */ 

extern void Beit see mpigenws: /* defined in 'slotted' process. * / 

extern int total slotted_arrivals; /* these two are globals defined in the */ 
/* slotted process a 

extern int EOLal slerred depareunes, 

extern int uM es; 
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/* the following globals aren't needed to be globals. Defining them as such 
/* keeps us from having topass numerous parameters just for tracking. 
/* Alternatively, we can keep them as state vars, but we'd have to pass each every 


< 
be 
4 


/* time we needed to update. We update on every received pkt, and one time at ENDSIM*/ 


/* We'll vary from good programming practices and keep them global. * / 
ARE total incoming _pkts; /* total pkts of any kind reaching ouree * / 
ING total good pkts; /* total pkts that passed sync and weren't PN coll’s */ 
Ive total voice drops; /* total lost = sum (failed sync + PN collisions ag, 
ete total pn_collisions; /* updated in DECODE state + 

aL gle t0tal syncuseatlures, 

tide total infogereserrors, 

double accumulated Ete delay, 

double accumulated THEO BER; /* these are all TDA values that are set in the +7, 
double accumulated ACTUAL_BER; /* pipeline stage. EbNo, Rayleigh, & EbNo BER are */ 
double accumulated NUM ERRORS; /* added TDA's (defined in mobile.h). these are *7 
double accumulated EbNo; /* some of the values we are wanting to track a 
double accumulated RAYLEIGH SNR; /* and monitor. See the *.ps.c files for morewmmeeeee 
double accumulated EbNo_ BER; 


Setele SIOUD Leen imuMse lS Celaya e007 0, 
Static double maximum ete delay — 0.0; 


Secunia me le Serer a tneominig PKES stathandle, /* they all need to be registered, kinda */ 


/* like checking in at the probe desk. 
Seaenancdleme total good pkts stathandie; 
peatvanaley vere delay stathandle; 
Stach ommecuLbenenpn collisions stathandle, 


/* the following is a matrix of polynomials that will be used to generate 
/* a PN sequence. 


int code matrix[NUMBER PN CODES] [REGISTER BIT LENGTH] = 
{ to, i =e, me ll ay = eye 


{2, 3, 4, a, =e =e, =a 
iy 2, a 4, ae q, Sole, 
{l, ay may =; ly ale =e 
or Vy ae ely ly sy Sy 
oy 3, a a =i =; Si 
{l, 2 J, 7, =; =. a), 
{2 3, 4, ay oF ae =e 
les 2 te a ee lee 
ay 2 4, SF 6, iL; Sly 
{2, 4, 6, ta Patio ree er, 
ee oF aF 6, ones ); 


a enniietton Delcarations ***/ 


/* an explanation of each function is offered in the function block where the */ 


/* function is actually coded. They are grouped by the state they are most 7 
7 Sapp lveable to. ai 
/ oot state Functions ***/ 

void Seeeregister to first state(short array([], int number of elements), 

vould generate pn sequence(short pn_code[}, short array[], int jx); 
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ry 
a 


Ehort find feedback(short register array[], int row); 
void rextejleten shift (shore samme 
void get_ next register state(short array[], int number of elements) ; 


P= SYNC State Functions ***/ 


short* Process the newloquy (Packet =pkpter), 

void look at SEabcuen wekethackes “pkpex); 

double eetract data open ereation time (Packet “pkern): 

double Borrelate USsyner Pies norte birt ptr, Shore sequence 1 tsumrmas, 


Eeoteame tag and store sihis mer acket “ pkptr,, Shore *bit ptr, List *1isSegeiae 


PA* SDECODE State Functions ***/ 

void Storey theelist or junk pkts(List *junk list ptr, int mimbervomen ams mEpkts)% 

int sorrelate — Wdaite bits (Packet* incoming_pkptr, short* pn_ sequence _ bit (Ser ,.eshore 
data[],double threshold) ; 

Sieeeeumepacketize recovered data(short *data bit array, int n_ data bits); 


/*** END SIM Function, Misc Funtions and functions used by all States ***/ 
void update _ Stgrsiint Witeheotau, ct lOat by how many); 














v7O1d epadate accumulators (Packet *pkptr); 

void ellean up event _list(); 

void eaean Up the _mess (Packet Peer ee SiOne = Memory ocr je 
void meeord final stats({); 

void print an array (char Segee string, ShOXE inegareray[), int a), 
int Piax number of shift register states; 

nt \max_ number | Pocus Correlations. EO ecOmputc; 

short \pn_ sequence array[PN_ CODE _LENGTH] ; 

short Sohint _register [REGISTER _ BIT LENGTH]; 

short \recovered  pomy array[REGISTERIBIT LENGTH); 

Short* \spreaded bits ptr; 

shnort* Neeeay Ot pers to pn sequences (NUMBER PN CODES]; 


double oy nic threshold; 

double \data_threshold; 

List* Peabray Of ptrs to packet list (NUMBER PN CODES]; /* as defined in mobi lesa. 
Objid Amy id; 

Boolean \long correlation; 

PN SEQUENCE A madera Xe of pn_sequences [NUMBER PN CODES] [PN_CODE LENGTH] ; 


: Temporary Variables 


objid emp 1c; 

int eee) 

ont nuMeevencs, 

pri number of data bits; 

ont number of packets __ in list; 

short data _array(DATA_ BITS]; 

double syne correlaevenm— 0.0, 

Boolean achieved Sync = OPC FALSE; 
Boolean cle N eodesmeheoeked = OPC FALSE; 
Boolean safe keeping = CPG MEAS, 
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Packet mopeecacea data pPkptr,; 
Packet *recovered data_pkptr; 
Packet ec ee hy ee ke m, 


Function Block 


[RR I IR III I I IOI IRB FR EO III TOI II TR Rt I IOI tk ek kkk ee / 


/* Function: set register_to first_state(), called from SYNC state 

inputs: int array[] = our shift register 

he number of elements = number of elements in integer array = shift register 
(ePRerurn: void 

/* 

{/@meEUrpose: This function is designed to accept an array of integers represemmeuae 
pe a shift register. The function will loop through the array, setting 
fe each element equal to zero, and set the LSB equal to one. 


/* Last Mod: 08/97, r.standfield@computer.org 


i! 


Gee RR KEKE EERE RRR ERR KR RRA KR KK RRR RK eR RR KER ER ie ee RR RR ee 


void 
Se@eaGlustcru EOQurtrhoe stedee  SnOnrk array |, ink numbergorectcn_ me 


{ 


mt ix, mn > number of elements; 

BOG ee — HO econ | s  ++a 3%) /* loop thru and set n-1l of them to Zerouew 
amray (ix) = 0; 

amieay | ax | =" 1; /* set the LSB == x 

return; 


D/] end of: set regismerm born lsroraec() 97 


[ERE KE RRR K KKK KEK KK KKK KKK KR RK REE KA RRR RE KEKE EE KR Kk RK LK Ke eS A ee 


/* Function: generate pn_ sequence () 

(= np Ot si: Packet* = pointer to pkt that will hold the generated pn sequence 

i array[]= used to represent the shift register for generating the sequence. 
ya This array is loaded with it's initial condition = 0xl from 

ee procedure, set register to first _state() called from the SYNC state 
yan int i = a row index to code matrix[][] defined in the Header Block. This 
i index will aid in determining which polynomial is being looked at. 
Io Pp array[{] = an integer array that will be set from calls withuieeaae 

oe £EuUNneeLoOn. 

pc Return: None 

pir 

/* Purpose: This function is designed to generate a PN sequence based on an 

ie initial cond ition. This function is called from the SYNC wcrc 

i and can be called several times. Initially, array[] is set to the 

ye first initial condition, Oxl. The first bit Of the PN Sequence bacum™ 
x upon the LSB of the shift register, = array[N] where N = 9 if array[] 
os represents a 10 bit register. The resulting sequence bit will be 

(e either 1 or -1, dependent on this LSB. Next, the feedback value is 

ee determined, based upon the characteristic polynomials defined in 

ie code matrix[}[].After obtaining the feedback (a different function 

i call), the shift register is shifted right one bit (another fumcevam 
ee call), and the feedback value is placed into the MSB of the shift 

es register. 


/* Last Mod: 10/97, r.standfield@computer.org 


“7 
+7 
7 
“a 
ae 
+7 
ae 
7 
a 
«7 
er 
7 
ae! 
ae 
7 
a 
a 
a 
a7 
aA 
mA 
a 
<a 
aA 


[8 RK kk ek ee ee ek ae ee ee ae kk ek eee ee ee eke ee ke ek ee ee ee ok kk kk kk ee kk ek ek kk ek kk ke / 
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woid generate pn sequence(short. pn _code([], 


( 


} 


short array[], 
Bx, Max length, n REGISTER BIT LENGTH; 
max length 


/* loop enough times to fill out the PN sequence 
=O; 1x < max Nength; ++1x) 


ab ray ime] 
find feedback (array, jx); 
irae. Shift (array) ; 


pn_code [ix] 


/* end of: generate pn_sequence() 


REG..LENGTH defined in mobile.h 


ieee te kek kk kee AAR AEE AA EAE KA AAA HAKKAR K RK KEK RE ee ek ek Ae REE ek Ee Ke Ree ke ee) 


/* 
/* 
/* 
/* 
/* 


find Leecbaew| | casted) from generate pn sequence) 

the shift register array 

(defined in the header block) 
This value was passed to 


register array[] 

the row index of code matrix[][] 
we are currently looking at. 
generate pn_sequence()from the SYNC state, and carried into this function. 


ae 
7 
ae 
aed 
ed 


eet AF eek kkk eee KEK KK KEK AKEKEAAR EK AEA KARE AR EKEAKKEKK KKK KKKKEKEAEK KK KAKEKAERER A AEE / 


Snort find feedback(short register _array[], int row) 


{ 


} 


ones count; 
OMe> count 


Bomtexe— 0; code matrix[row] [1x] >= 0; ++1ix) 
Peeosmeount += register array[code matrix[row] [ix] - 1]; 


Peeummaones count 


/* end of: find _feedback() */ 


[8 RK Rk kk ke ek ee eee eee kk tk RII II kk ok ok kk kk kk ok kk ok kkk kk ke 


/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
vy * 


Sit@tectitit( called —rnom generale pn sequence (= 


the integer array representing the shift register 


This function is designed to accept an integer array of length 
Peel olER BIT LENGTH as defined in mobile te The funectiom will shire 
each value of the register one place 
will set the first bit of the register 
This value is overwritten in the calling function, 
ensure it has a value and is not an unknown, 
r.standfield@computer.org 


EO the righty 
completion, 


we set it here. 


or 
ey 
ay 
=a, 
oy 
Me 
7 
ac 
ae 
aa 
aah. 


[% RK OK Rk ee ek ek ee Re ee kkk ee kk kek ke eek rk tee kkk ok ek kk kk ok ek ke kok ok ke ee 


voOld 
Eeghteshitt (short array([]) 


{ 


ee eeeimmot: raght, Shitt (} 


1 Geese 
Pi Veeteitieestlrt (short array! |) 


/* loop through N-1 times, 


and shift each bit over ibyacone=s/ 


Pomoc REGISTER BIT. LENGTH=l; ax > 07; so -ix) /* start at the end, work back xa, 
eae ix) = array lix-1); 

array[0] = 0; /* be safe, set the first bit (MSB) */ 

FOUT 


a 


PREP ERR IR EA A KALE EA RRR A ERIK AE KK RK RK IR TE ea ee 


/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
f= 
/* 
7 
es 
/* 
/* 
J = 
i= 


Pune Eason: get mext register state(), called from SYNC State if called vane 7 
inpiites int array[{] = the array representing the shift register. xf 
number of elements = number of elements in the array * / 
Return: None */ 
sy 

Purpose: This function is designed to accept an array of integers representing aay 
a shift reg.The function works as a counter. It will determine the next state 74/7 
of the register, based upon the current state. If the current state == 0001, a 
next state == 0010. The register is assumed to be used with generating maximum */ 
length sequences for generating a PN sequence for Spread Spectrum i 
applications. The state of the register should never reach the ALL ZEROS state, */ 
or the generated m sequence would result in nothing but zeros from this point. */ 
Thus, an all zeros check is incorporated. If found in this state, the retwe meme 
is set to state ONE, ie state == 00001. If found in the ALL ONES state, the af 
register (counter) will roll over. ie if current state == 1111, next xy 
state == 0001. x / 
The function is designed to work on any length of array, providing the correct */ 
number of elements is properly passed in. * / 
Assumptions: array is of short minimum n = 3 elements. If not, for(j=i+2...) by? 
loop will be out of bounds * / 

* 

/ 

Last Mod: 08/97, r.standfield@computer.org * / 


[RRR RRR KKK KKK RRR KK RR RR ek RR a RK KK kk a KK KK KKK KK KR kk ke kk Ke ek kk Ak ka kK Ke Ak 


void 
JormnewaeeegiSster Stawen short array([], int number of elements) 


{ 


Perm) k—1 x axe Son; ot +) x) 


/* initialize with an array element, 


any will do*/ 


ltalite xj 
siionte all ones; 
gmt zeros check = 0, n=number of clements, 
home —- O+ “Px —en—l) +41) 
{ 
all ones = array[ixtl]; 


all ones &= array[jx]; /* we only need to know if all elements after a 
/* the itth element are "sere one +7 

eit yx ea lone s ; /* the i'tth element = 1 on XOR of two “7 
/* Seondi tions: * / 


} eo 
/* 


i 


either it's already a one, 
elements are 'l' 


or all following 
and it's time to ‘roll* 3m 
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Pera yin-)) “= 1s /* toggle the LSB each time. 


morerx—O; ix < nj; ++ix) /* leopethrough acca. 
zeros check |= array[ix]; 
if(zeros check == Q) /* if all. bitse®=—aC; 
array(n-1) = 1; /* next state to the OOO.... 
return; 
Me end of: get next register _state() */ 


Biert™~ process the new_guy(Packet *pkptr) 
{ 

jake packeunlengen, 

double ete delay; 

Beeleane processed ok = OPC FALSE; 


Buetee* bit ptr = (short *) OPC_NIL; 


if (debug == VERIFY NUMBERS || debug == SHOW ALL) 


Teoe@lmdiestats Of pkE(pKpEr); 


Sisemaelay = op sim time() ~ extract data_pkt_ creation _time(pkptr); 
Ponemum ete delay = minimum_ete _delay < ete _ delay? minimum _ete delay: 
maximum _ ete _delay = maximum_ ete edelay)- cce dela ax imunyeecmadema 7: 


if(ete delay > MAXIMUM _VOICE DELAY) 
update stats(VOICE DROP, ADD_ ONE); 


Deeaeesaccumulators(pkptr); 
BigeeecmotatsS(ETE DELAY, ete delay); 
update _ stats (NEW_ ARRIVAL, ADD ONE); 


BeiGpeek nid 1s set(pkptr, “SPREADED DATA”) ) { 
Peep pk - nfd _get (pkptr, "SPREADED DATA", 


processed ok = OPC TRUE; 
} 


Meeenrecessed ok) { a 
Steaieip the mess(pkptr, bit _ptr); 


Opysim message ("DESPREADER2Z:SYNC STATE:process the new_guy()."™ 


Ze7 OS (elcek 


&bit per) 


ti 


checking for all zeros eo, 


set a 
ty 


eceucelay. 
eve cde lag 


"Failed to get the memory address for the SPREADED BITS. Runts += 1"); 


update stats(RUNT PACKET, ADD ONE); 
} 


Peeuem(bit ptr); /* null or otherwise, 


} /* enf of: process the new guy() */ 


depending om Op pk inedigeu() ai 
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void 
P~@ieaeeotats Of pOkt(Packet *pkptr) 


{ 


Cay toe radiowxmer 2d, xmtr id; 
Shiokeesmememame:| 10) > 
Gidt spreading code [20]; 


/* get the id of the transmitter object which sent this pkt 7 
radiom=mtr td = op td gét int(pkptr, OPC TDA RA Tx OBgD); 

/* now get the parent of this radio xmtr, which = the node that */ 
Pewcent this pkt. a7 

(emeteGr—a Gp EOpO parent (radio xmtr id); 


/* if this xmtr node has a name attribute, see who sent this pkt */ 
Pi(oretiid Cbgmautr Cxists(xmtr 1d,;. “namewj. —— Oe iRws) 
{ 
op ima obj attr get(xmtr_id, "name", xmtr_name) ; 
eon mao joy RaEtr egeetsmtr wad “polynonval spreadinguceda): 
printf("Pkt came from = $s.\n", xmtr_name); 7 
Petiet( wekuespreading Code = es. \n",. sprcadungucedc s. 
prantf("Pkt from %s, id = %@d, Start TX = 6f.\n", xmtr name, op) pk tdi pee 
op tdi getedbl(pkptr, OPC TDAURAY START ERS thes 
s id = %d, End TX = $£.\n", xmtr _nhame, op pk id(pkoumm@ 
Op td) qetedsl (pkptn;. OPC TDA RAUEND Rao 
CLinci( eicetnom you ide —8td tart eR. — tn \n xen _name, op pk id(pkptam 
op td_get_dbl(pkptr, OPC_TDA_RA_ START RX)); 
PEintit PKE from ss) 1d = td, End RX = $f.\n", xmtr name, op pk id(pkpuae 
ep td get dbl(pkptr, OPC TDA RAVENDa a) 


oe 


Om ioe “Pheer com 


} 
else 
ep Sim message("NO NAME ATTRIBUTE of transmitter for Enis pke! Wy Fee 


ey ee@edeltook atostats Cf pkt() ~/ 


double 
Sxieeatebeaddta pkt creation time( Packet “~pkpEr) 


{ 


Gememe okt creation time = 0.0; 
BeOleaneeagotsthe tame = OPC BALSE; 


/* the original pkt creation time has hopefully been passed along, as this 7 
/* pkt has undergone several face lifts. We'll attempt to extract and return */ 
/* the info here. * / 


Pico emis aset (pkptn,. “creation time) )4 
ir Pom _pk_ nfd _get (pkptr, "creation time”, &pkti Creat Gemini. 
meget ene time — OPC TRUE 
} 


/* it we didn't successfully extract the pkt creation time, ware the users 
eee sehen t -Lme } 
cop olimilessage. ( DESPREADER: extract dataypkt (Greatiemmeime(): 7 
"Pailed to extract original pkt creation time. ETE data is bogus. 
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return (pkt_ creation time); 


} /* end of: extract data _pkt_creation_time() */ 


cet eek eke keke kee eK EKA KEKKEKEREKEAKKKAEEK KR KA KK KK EK KKK KK ERE A KK KH KA EK A A he KAR ee / 


/* 
/* 
/* 
/* 
/* 
/* 
7 * 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 


Function: correlate syne bits(), called from the SYNC state: 
input s : incoming pkptr = the pkt received in the receiver 
pkptr2 = the pkt containing a generated PN sequence 
num of sync bits = a simulation parameter, globally declared in the 
a ae ~ header block 
Return: the correlation value obtained from the cross correlation of 
two sequenees 
Purpose: This function is designed to cross correlate two binary sequences. The 
first sequence is from the passed in packet, which is the pkt received 
in the receiver. The second sequence iS a generated PN sequence, based 
upon a particular poly nomial. This function may be called numerous 
times in am attempt to achieve synchronization with thesanecomimogee ce 
Last Mod: 9/97, r.standfield@computer.org 


ae 
ae 
ae 
a 
oy. 
ee 
Ey 
ae, 
ay 
ye 
Sif. 
7 
a 
aa 
ih 


tee eek kk hak Keke he KKK AK AEKKEAKRKA KARE EEER EERE EAR EK EAE RK KA AEE A eS eee ea 


Seelolencorrelate sync bits(short *bit_ptr, short *sequence bits _ ptr) 


{ 


int ix; /* SYNC BITS and PN CODE LENGTH are defined in mobile.h */ 


Paem@eme int ptrl, *int ptr2; 

static miesplacesholders([3)[3].= { { 1, 0, Be 
{ 0, 0, S305 
t=; oF le ey 


ie sum = QO; 


tieeeerl = bit ptr; 
Poe, 1x < SYNC BITS; ++1x) 
{ 
Beemeptr2=sequence bats ptr; int ptr2 < sequence bits ptr + SYNC BITS PG; 
+ Pee ee lyee ++ 1 teers 
eeme+— place holders[{1 + *int_ptri][1 + *int_ptr2j; 


} 


Peetemiadouble) sum / (SYNC BITS PG * SYNC BITS)); /* our normalized corr value */ 


me, end of: correlate sync bits() */ 


Boolean 
Meemancaestore this pkt(Packet *pkptr, short *bit ptr, List *list ptr) 


{ 


Boolean its in the bank = OPC_FALSE; /* its in the mail, and I luv you no .... */ 


/* op pk _nfd_set() will abort the program if passed a null */ 
/* pkptr. it's worth a couple of machine instructions to check 


meuewerr != (Packet *) OPC NIL) { | 
mowep pk nid set (pkptr, "SPREADED DATA", bit ptr, Op Pro umem cee, eercaea, 
op prg mem free, (SPREADED LENGTH*sizeof(short))} == OPC COMPCODE §SUCCESS) 
{ 
/* if we were able to reinsert the ptr to our spreaded bits in the pkt, i 
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at 


7* then we can insert this pkt in a list we are maintaining. Unfortunately 


Pao peel toemerasert()returns void. It will abort the run if passedvau ao 
/* illegal list pointer or malformed list (whatever that is, I can think of 
/* several I guess). Lacking any complete and exhaustive method to ensure +4 
/* ensure this doesn't happen, we at least (hopefully) reduce the probabilityaw 
/* by checking to ensure the pointer is !null before making the call. <7 
iiilist per '= (Lise *) @ec Ni lve 

Sorprg l1stgansert (lrect ptr, pkptr OFC isl Osman, 

/* since Opyprg list insert() returns vold, we COUED teacces— a aes ey 

/* ensure it went smoothly, i.e. if(copy of pkptr == op prg list access x 

/* (TATIL))..., but we could be checking for errors ‘till the cowsuecome at / 

/* home. flag it TRUE and let's get out of here. * / 


Bes linet romoank — OPC ULRUE, 

} 

else{ 
/* else for whatever reason, the list * is null, leaving no place for the wjoiuuee 
clean up the mess(pkptr, bit_ptr); 
op sim message ("DESPREADER:tag_ and store this pkt()." 

— ss "Hist* is Null. No safekeeping for pkt, it's gone!"); 
} 
} 


else{ 
/* bit ptr points to our spreaded data bits. if we farled to inser aaa a! 
/* address back into our pkt, the pkt is of limited if any use. we do stu 
/* have the ptr to memory where all of these bits are stored. we could 7 


/* access them, but we have no 'train' to put them on. we'll just evict theme 
/* by freeing up the memory they are holding, then we'll take the broke down */ 


/* Chevy they were supposed to ride and melt it down for scrap metal. No a 
/* need to fool with the list, as we have not manipulated it in anyway. es 
clean up the mess(pkptr, bit ptr); /* clean up a little and alert the soa ay 


op sim message ("ERROR: DESPREADER2Z:from SYNC state:tag andstore this pkegim 
"Failed to ee the spreaded bits ptr address into the pea 
Datapis HOSits. ); 


J/eebut don't screw with the list or the list ptr. it's fine. tmem ieee be 
Pee ust. docsn | begqrow . Z «/ 
} 
} 
else{ 
/* else if the pkptr passed in was null, don't waste our time. clean house, a 
/* same as above 7 
if({bit ptr != (short *) OPC NIL) /* if they passed us a null pketr7 moa ba / 
/ /* likely this is null */ 
op prg mem free(bit ptr); /* as well, else where did they get it? = 
| ~~ - /* but with some folks, you never know. <7 
/* if it does exist, free the memory | 


Op sim message ("ERROR: DESPREADERZ: from SYNC state: tag and store Ehis pheage 
"Failed to reinsert eae spreaded bits ptr address into the i 
Patagis Lost..)e 
} 
Boweiebes s Li wene oan kK); 
ee eidmort: Cag-and store this spkt() */ 
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Old 
Smety the list of junk pkts(List *junk_list_ptr, int number of junk pkts} 
{ 

Poeket *junk pkptr; 

short oe) Ce INE SS te tae 

int ax 


y* loop through the list, remove the pkt from the list, and destroy it as a lost “*/ 


/* pkt. each removal from the list will make what was the second pkt now the */ 
/* first pkt in the list = OPC_LISTPOS_ HEAD. need to also free up the memory x] 
/* each pkt has allocated for the spreaded bits. * / 


for(ix=0; ix < number of junk _pkts; ++1x) 
{ 
Memiemokptr = (Packet *) op prg list _remove(junk list ptr, OPC LISTPOS HEAD); 
mepank pkptr != (Packet *) OPC_NIL){ _ 
if(op pk _ nfd_ get(junk_pkptr, "SPREADED DATA", &junk bits ptr) == 
OPC COMPCODERSUGEES.) 
clean up the mess(junk_pkptr, junk_bits ptr); 
else { 
op sim message ("ERROR: DESPREADERZ:empty the list of junk pkts()", 
"FAIL ON GETTING JUNK BIT PTR ADDRESS FROM PKT"); 
ep Sim message (“UNABLE to Deallocate SPREADED BITS bytes) of memory aa 


} 


/* else, do nothing. how could a pkptr in the list be null? ays 
/* else, for some reason, the list of pkt pointers has a pkt address which a), 
/* is a duplicate of one already dealt with. If this is the case, we do not */ 


/* need to process it or release its memory, as that has been done. This ry. 
/* should not, forseeably, ever be the case, but it ain't ever supposed to es 
/* rain on a parade either, so who knows. Calls to op pk _destroy() with a a 
y*snull pkptr will abort the program, and it should be checked” prior: ae 
} 
return; 


m/* empty the list of junk _pkts() */ 


ieee KKK KKK KKK KKK KK AKA KAKA KEE KKK AK EEK HK AEKKEK KER EKER EHR ERK eK KK KA Ke A eek ee kee / 


@ Function: correlate data bits(), called from DECODE state, if called at all m/ 
meeliiemiss Packet* incoming pkptr = the spreadéd data pkt, need to despreéaad this pkt */ 
y* Packet* pkptr2 = a pkt containing our pn sequence which was recoverd from uy 
* our. synchronization function. If the pkt reached sync, we were able to oy 
_* recover the pn sequence with which is was sent. * / 
_* int data[] = an array that will hold the data that is recovered * / 
_* int threshold = a simulation parm, user definable, that is the threshold af 
> we must meet in our cross correlation in order to accept the data bit. a) 
fe Return: int data bits = the number of data bits determined to be in the pkt ney, 
:* x / 
y* Purpose: This function is designed to receive a packet of data bits that has er 
.* been spreaded with some pn sequence. The bits of the respective data pkt ay 
:* are cross correlated with the pn sequence passed in, and compared against bay 
.* the threshold passed in. The retrieved data bit is determined to be either Af 
:* al (one) or O (zero), depending on the correlation value and threshold. If */ 
és the threshold is not met, the value of -1 1s set within the array. The sy | 


Ih 


i DiitComeOumcdtdsbltls 1S returned to the calling function for later vise: “7 
ie */ 
/* Last Mod: 9/97, r.standfield@computer.org +7 
(eo ee OK AR KKK AA KK A A RE KK KK RRR ke KR Re Ke RR RE R Rk ek Ae 
PIs 

Set eetleemeadeagol es (Packet? Iincoming pkptr,, short* ph_sequence bit ptr, sieme 
data[{],double threshold) 

{ 


Sethe Poot nlengtin, code length, smunber sof -datar bigs, 
SCRE se Silene tr, 
Shont *spreaded data bits ptr; /* we have a State Var: spreaded biitsipem a7 
/* OPNET barks if a functions proterve= 7 
SHObE as “Ditepur, /* vars matches a State Var. be careful. 777, 
Shelia  lOoembounds ; 
Seat ue anit Blaceghe lees (Si) (2]) = eal) eens, 
{ 0, OF Ol, 
(=a, Oy Lae 
TMi Sum =a. 
deuble “correlations — Us0yex<corr = 0,0; 


/* MAC BITS, SYNC_BITS, and PN CODE LENGTH are defined in mobulemm 
bit length = op pk total size _get (incoming _pkptr); 
number of data Weta a aryiewae _length > - SYNC_BITS*SYNC_BITS_PG)/ DATA BITS PG —- MAC3Biiiee 
code _length DAT AS BiTSShG, 


/* get the pointer to the spreaded data bits. */ 
1£{(op pk nfd get (incoming pkptr, “SPREADED DATA", &spreaded data bitsipim mes 
OPC _COMPCODE_ FATIURE) 
op sim message ("DESPREADER2: correlate data _bits().", 
"Failed to get memory adress for the information bits. Data is loses 


/* the pointer obtained is actually pointing to the start of our spreaded data a 
/* bits. They consist of: 1) spreaded sync bits, 2) spreaded mac bits, and 3))6mueee 
/* spreaded information bits. All we're really after is the spreaded information */ 
/* bits. The sync bits were used to correlate for synchronization in the SYNC _ 
/* state, and apparently passed sync, or we wouldn't be here. we'll effectively */ 
/* 'strip' the sync and mac header bits by skipping past them, then correlating ar 
/* what data bits we have left. * / 


/* set a working ptr to point past the sync and mac bits, starting at the first 1p 
/* data bit. Then, loop through the remainder of the spreaded data bits and ie 
/* correlate them individually with our pn sequence. Our pn sequence is the one */ 
/* which this particular pkt was synchronized on, thus we are reasonably sure it */ 
/* was the same pn sequence used to spread the data. If the correlation meets + 
/* the user defined threshold (passed in to us), we set the data bit as alor0O */ 
/* accordingly. if the correlation falls below the threshold, we flag the data <), 
/* bit as a -l. The data bits are put in an array that was passed in from the a7 
/ Secalling cunction (DECODEMSigate) « a 


loop_bounds = pn sequence bit ptr + DATA BITS PG; 
bupeorr mecoreaded data _bits mpt Yeet SNC « BITS*SYNC »BITS PG + MAC BITS*DATA BITSREee 
for(ix=0; ix < number _ oie Gdiittacbiea, ++ix) { 
for(int ptr = pn_ sequence _ bit _ptr; int _ptr < loop bounds; ++bit_ ptr, ++intgeaee 
/* we loop through our pn sequence array a total of data bits Eimes asm 
/* each data bit was spreaded with the entire pn sequence. 7p 


iz 


sum += place holders (a+ *bit ptr] |) intioews 


/* sum +=) (*int (ptr) sb tomer 
} 
/* set the array value with the respective value, and reset sum = 0*/ 
xcorr = (double) sum / code _ length; 

@ata[ix] = (xcorr >= threshold) ? 0 : ( (xeorr <= -thresholadme |e. 
meidatalax] == -1) 


mMacdate Stats (INFO BIT ERROR, ADD_ONE) ; 
sum = QO; 

[eeeeenad of: for ix < number of data bits */ 

/* now that we're done, we no longer need the memory storage for our spreaded */ 
y= data bits. and since the pkt is holding no information and is of no use, , 
Peewnat the hell, destroy it too. * / 
Pleaneup the mess(incoming pkptr, spreaded data bits ptr); 

Meee emreturn data bits. this could have been determined from sevé®al different */ 
[eveys, and is actually a hold over from earlier evolutions of this coding. ah 
/* It ain't broke, so we aint’ fixin' it. */ 


Sromamumber of data bits); 


me end of: correlate data _bits() */ 


ee eee AKER KKK eK KEKE KKK AKER EKER KAR EK KKK KKEEEKEKKEKEKEXREKEKEEEKIEEREKEKKR KKK EEK KE / 


’* Function: packetize recovered data(), called from DECODE state * / 
= inputs: Packet* pktpr = pkt that will hold the data * / 
:* int data _array[] = array that contains the data. this array was set in the ei 
_* correlate data _bits() function and should be filled with any and all data */ 
_* bits that were successfully cross correlated with the spreaded data pkt. i 
.* mamEnumber Of data bits = the number of data bits that weme reported) eco m 
:* overed from the correlate data_bits() function. It keeps us from running */ 
. off the end of the array. « / 
f* Return: None * / 
.* * / 
o Purpose: This function is designed to receive an integer array representing data.*/ 
_* This is the data that our receiver has 'successfully' recovered after the xe 
_ pkt has passed synchronization, has had the sync bits and the mac header rH 
_* stripped, and the remaining bits of the pkt have been cross correlated * / 
_* with the corresponding PN sequence and the resulting data recovered. As an oe 
_ afterthought, this pkt could have been, or could be constructed at the time */ 
a the cross correlation is performed. */ 
¥* Last Mod: 9/97, r.standfield@computer.org x / 


ee RR EK KKK KH KKK KKK KEKE KKK KEKE KEK EEK EERE EERE H ERK KKH KR KK ee we ee ek ek kt) / 


macket* 
meeketrze recovered data(short *data_bit_array, int n_data bits) 


{ 
peeeeme cata bits ptr= (short *) OPC_NIL; 
Paekee, “pkptr = (Packet *) OPC _NIL; /* guilty until proven imnocenta.-7 


Vawcreate a pkt that will hold our data */ 
Pee Op pk create fmC("™DATA PKI”); 
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} 


Pee soere— (Packet *) OPC NIL) /* don't assume! */ 
{ 


/* next, allocate enough memory to store the data bits. */ 


Saeaeolese Pere (Short op prg memvalloc(n data bits*sizeot(shore 

mieten weleseper != (shore *) OPC NIL) /* any memory available? */ 

{ 
/* cool, we have a newly created pkt and a place to store the recovered data.*/ 
/* copy over the data bits into this newly allocated memory spot, insert *Y, 
/* the address into the pkt and we're done. what the hell, print out the piu 
[So tne user will think Something ts) goingscninenen—e +7) 


Op prg_mem copy(data_bit_ array, data bits ptr, n_data bits*sizeot(sho, aan 


/* insert the memory address into the pkt.*/ 
if(op pk nfd set (pkptr, "DATA", data _ bits ptr, op prgq mem) cepyecmeaecs 
op prg mem free,n data _bits*sizeof(short)) == OPC _COMPCODE FAILURE) 
{ 
/* if successful, no action required, as the address has been set. If it */ 
/* failed we need to free up the allocated memory, destroy the pkt. and gt A 
/* alert the user * / 


clean up the mess(pkptr, data bits ptr); 
op_sim _message ("ERROR: DESPREADER2: packetize_ reCOvereduGdeaea am: 
"Failed to insert etc ‘data bits Address - in pkee 
Data 2s lost."); 
} 
} 


else /* else we are having memory problems. bummer. clean up a little. a 
{ 
/* no need for the pkt we created, destroy it. it's !NIL, or we'resmm *y 
/* the wrong bleck x / 


cleanup ene mess (pketr, data bits ptr); 
op sim _message ("ERROR: DESPREADER2: packetize recovered ie@atai a 
"Failed to allocate memory for recovered data bits. 
Data 1s lose] ea 
} 
} 
else /* else we failed to create a pkt of format "DATA PKT", bail. */ 
{ 
op_sim_message("ERROR: DESPREADER2:packetize recovered _data()" 
"Failed to create Packet of fotmat DATAR SKE oDatea i lost. SO SOXET Yam 


} 


return (pkptr); /* it's either still OPC_NIL or has been assigned a good addi aa 


/* end of: packetize recovered data() */ 
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mold supdate accumulators (Packet *~pkptr) 


{ 


eeecumulbated THEO BER += op td get dbl (pkptr, GERIr ye ae. 
aceumulated ACTUAL BER += Op td get sda wien per Ore ST phe RA_ ACTUAL BER); 
accumulated NUM ERRORS += Op td Get simente qocis Ceol le RA_ NUM _ERRORS) ; 
accumulated EbNo OD a facie G65 Ucbl (ekeea, OPC_TDA_ RA MAX INDEX 


+ ADDED TDA RA EbNo); 
accumulated RAYLEIGH SNR’ += op td _get_ Dabiitokoe:, OPC_TDA RA MAX INDEX 
= 7 + ADDED TDA RA RAYLEIGH SNR); 
accumulated EbNo BER i ome! _get_ Nabi (pkpen: OPC TDA_ RA MAX INDEX 
+ ADDED TDA RA EBNO _BER); 
recurn; 


} /* end of: update accumulators() */ 


{ 


void 
BecOrd tinal stats () 


a oie earal lost pkts = total pn collisions + total sync fairies, 


/* we merely keep track of voice pkt losses. they are not included in the overall pkt 


less prob. */ 


gotiemes okt loss prob = (double) total lost pkts” 7 totalUslotreedgarri aie 
Semeeemevorce pkt loss prob= (double) total_voice drops / total slotted arrivals, 


Oop sim message ("DESPREADER2:DESPREAD.", "WRITING FINAL ACCUMULATOR STATS") ; 


/* we assume on this next call, that we are in a Single cell, and all xmtrs */ 
/* are matched to our receiver * / 


Opystate scalar write("Total Number of Users", (double) 
Gemeepomooject count (OPC_OBJTYPE RATX) ); 


Op ysmese, SCalar write ” 
Carseat scalar _write ” 
Op stat "scalar MEabe Total Volce prous - 
op stat scalar write("Total PN Collisions " 

” 


("Total Incoming PKes 

( 

( 

Bi = ( 
G@pesiaeescalar write("Total SYNC Failures 

( 

( 

( 

( 

( 


"Total Good Pkts 


(double) total incoming pkts); 
(double) total goed) pres, 
(double) total voice drops); 
(double) total | Prhacollvstens y 
(double) total sync failures); 


Opestat scalar write("Total Info Bit Errs (deuble) total inteisitgerroma 

op stat scalar write("Total Runts. ,(double) runts); 

Speoeeae scalar write("Minimum ETE Delay. aaa minimum ete delay); 

Sersteat _scalar_ write("Maximum ETE Delay. ", (double) maximum_ete delay); 

So stat Zecalar _write("Average ETE Delay. °", (double) (accumulated eterdelay / 
total 1ncomingmp cis): 

Semeseaesscalar write("Theoretical BER ", (double) (accumulated THEO UBER y 
total | _inéeocmingsp cs) )- 

op stat scalar write("Actual BER ", (double) (accumulated ACTUAL BER / 
Cotal _ incoming mokES)).; 

@eestac Scalar write("Total Num Errors ", (double) accummbatedsNUM ERRORS }j; 

op stat scalar write("Avg Num Errors/ pkt ", (double) (accumulated _ NUM _ ERRORS i 
focal: _ incoming SOKCS) 

op stat scalar write("Average EbNo ", (double) (accumulated_EbNo 
Lotal Incoming pieesine, 

op stat scalar write("Avg Rayleigh SNR ", (double) (accumulated _ RAYLEIGH SNR / 
total incoming _ pkts) ); 

op stat scalar write("Average EbDNo BER ", (double) (accumulated EbNo BER  / 


total incoming pkesiy. 


nS 


Semoeemocalar write(”Pkt Loss Prob 1 ¢ \O0uUD Le) Senex Voss ioscan 
Ppeceemscabar werte("Voree Pkt Loss Prob ", (double) voice pkt loss prob); 
Seesear scalihir write("Sim Time (sec) op sim time()); 


™= = ™ 


ley eneeor: record final stats() *7 


/* the following function is used merely for debugging purposes. it does the obvious. */ 


void 
Puintwanmarray (Ghar ~char. string, Short Inieoarray |) jane 
{ 
Digs sc, 
PeCeeiar esuring !— "\O") /* if a null string was passed in, skip it, 7 
/* else print it * / 
Paint ts. Char estan), 
Ores Oe oem oe) /* printf out the contents, assumed to be short a 
faints: MeL Kkewol cs * [| 


ieee SA ING at ray | lee 


Peine teen, 
ee) eecieloi. (Obit al arway ee 


vold clean_up event list () 


{ 


Bvaamaie Nthts cvent, Next event, temo event, 


Ents event — <Opucy Gurren), 
next_event = op ev_next_local(this_ event); 


Wine oer evy Valieinexe. ev cme): 
{ 
/* check all scheduled events to find any that were scheduled from the SYNC state */ 
1f((op_ev_type(next_event) == OPC_INTRPT SELF) && op ev_code(next event))== 
SYNC_ACHIEVED) 


{ 


Eel event = Mext event, 
nese Nevciee= (Op ev next local (temp evene), 
HE{Op ev pending(temp event) == OPC_TRUE) 


{ 


/* we have pending events scheduled from the SYNC state. these are events */ 
/* that we can cancel, as all pkts that passed sync have been dealt with. */ 


Op_ev cancel (temp event); 
} 
} 


else 
eee OMt se wOWne Vane tmLOcal (next evene),, 
} 
i? end of: clean up event list() */ 
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Oud 
update stats(int which_stat, float by _how_many) 
{ 
Switch(which_ stat) 
{ 
case NEW ARRIVAL: 
total _incoming_pkts += by how many; 
op stat write(total_incoming_pkts_stathandle, (double) total_incoming_ pkts); 


break; 
mace GOOD PACKET: 
EOuakegQoodypkts += by how many; 
op stat _write(total_good_pkts_stathandle, (double) total good pkts); 
break; 


case PN COLLISION: 
Betal pn collisions +> by how many; 


op stat_write(current_pn_collisions_stathandle, (double) by how many); 
break; 
ease) JOLCE DROP; 
mera vOICe drops += by how_many; 
break; 


case SYNC FAILURES: 
iPgeatesync failures += by how _many; 
break; 

eaceeRUNT PACKET: 
runts += by how many; 
break; 

@aaee hte DELAY: 

Beeunulated ete delay += by how many; 
op stat _write(ete delay stathandle, by how_many); 
break; 

Gase INFO BIT ERROR: 
Seeieeinto bit errors += by how many; 
break; 

default: 
break; 

} 
me omencmor: update stats() */ 


void 
eiean up the mess(Packet *pkptr, short *memory ptr) 


{ 


/* check the passed in memory ptr. op prg mem free() will abort the run if passed ais 
/* a null ptr. Too, we sometimes use this function to deallocate memory, or to af 
/* destory pkts. When doing so, we'll pass ina null ptr for the other parm to keep */ 
Paeenewcompiler happy. this null check gives us a little flexibility and hopefully —~/ 
p wamertele quality assurance. if either ptr IS null, just ingore it. ne 


if(memory ptr != (short *) OPC_NIL) 
op prg mem _free(memory ptr); 


if(pkptr != (Packet *) OPC NIL) 
seme Gestroy (pkptr); 


mey* end of: clean _up() */ 


I 


INIT State 


(lei ceases. who. leame. * / 
my id = op id self (); 


/* go get our runtime parameters of the simulation */ 
/* all of these simulation parameters are user defined for the simulation a7 
/* sync threshold = the threshold we must meet in order to accomplish synchronization*/ 
/* data threshold = analogous to sync threshold, it is the threshold we must meet a 
ha im order to consider the data information sdecodalle * / 
/* long correlation is a user definable Boolean (toggle) simulation parameter. If “oh 
/* toggled TRUE the following WHILE loop will, if necessary: * / 
es for each PN polynomial (defined in code matrix() [i> * 
ye generate a PN Sequence for every possible initial condition of the shift 7 
/* register (a phase shifted version of each other) x / 
f= correlate the received incoming pkt with each generated PN Sequence + 
/* that can take a bit of simulation time. Without a loss of functionality, Vong ay 
/* long correlation is defaulted to FALSE. The below WHILE loop will load the shift a 
/* register with the first initial condition = Oxl, and will only check one initial a 
/* condition per PN sequence. this allows dramatic savings in run time simulations, a 
/* without losing the intent. the transmitters shift registers default initial load a 
7 elcome s ane ao a7, 
Spe Mas Oop eaAbt reget Mmyntd,,) syne threshold”, &sync threshold); 

Gplimalsobieaterege tim id, ncatan thmesinoilcds &datd “enEeshotas 

op ima obj attr get(my id, "long correlation", &long correlation) ; 

/* provide initialization for some of the state variables a, 

/* state vars cannot be initialized at declaration. this is ty, 

/ meade Us, venus we should initialize them Mere Co prevent xi 

/* unexpected results oy 

Eotal ineoming pkts = 0; 

Eoeclagq@ecdepkts nO 

total voice drops = 0; 

Ee enecollisions = 0; 

Eel syvMc  Tallures = 0; 

Seed ebiee sole errors = 0; 

So pe Keceiamg = OPC FALSE; 

accumulated ete delay = 0.0; 

accumulated THEO BER = 07 05 

jecumulated ACTUAL BER  — "ONO, 

accumulated NUM ERRORS = 0.0; 

accumulated EbNo = 0.0; 

accumulated RAYLEIGH SNR= 0.0; 

accumulated EbNo BER 0.0; 


/* based upon REGISTER BIT LENGTH defined in mobile.h, determine */ 
/* how long our pn sequence should be. ay | 


heewiiioeoasor shirt register states = pow(2, REGISTER BIT LENGTH) - 1; 
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max number of correlatvons —ececomputes— 


long_ correlation == OPC_FALSE ? 1: max number cf Ushi i yreqtst- ogee =o 


/* FALSE is most likely */ 


/* register our statistics handle, allowing our probe file to sample the output i 


motal incoming pkts_ stathandle =_Op Stat req("Total @incomimngyeikas | 
OPC_STAT INDEX NONE, OPC STAT LOCAL) ; 
total good _pkts_stathandle = OP sStat, reg ( Tetale Goede hices | 


OPC STAT INDEX NONE, OPC STAT LOCAL); 


Seendelay Stathandle = Gomotcie _reg ("ETE eta 


OPC_STAT_INDEX NONE, OPC_STAT LOCAL); 
current pn collisions stathandle_ = op stat reg("Current PN Collisions", 
OPC_STAT INDEX NONE, OPC STAT LOCAL); 


/* This model is intended to model a CDMA SS system. Thus, 
/* simultaneous multiple access within this receiver. 


we want to allow 
In our SYNC state, we 


/* do several things, which we will see, but a note is worth explaining now. 

/* We'll have to correlate each packet that is received to determine if we can 

/* decode the pkt. Errors induced in the error.ps.c pipeline stage could render 

/* the pkt as junk of course. Assume the case of simultaneous reception of two pkts. 
/* Assuming they both were correlated fine and were determined as ‘'good' pkts, we 
/* need to also determine if they were sent using the same or different PN Codes. 


/* If the same, then we have a ‘true collision' 


and the pkts get destroyed. If 


/* different codes, then we're ok. As pkts will assumingly arrive at the receiver 


/* at the same time (equidistant xmtrs, slotted MAC), 


we need to maintain all of 


/* the pkts until we have processed all that were simultaneously received. Once all 
/* have been processed, wecheck for duplicate PN codes and deal with those pkts then. 


/* we accomplish this by placing the pkts in a linked list. 
y* array Of pointers pointing to the linked lists. 


the below array is the 
The indices of the array will 


/* match the index of the pn sequence which the received pkt used, based on the 


/* polynomial that was used in the transmitter. 
Memeeder block of this process, in code matrix[][]. 


The polynomials are defined in the 


/* For example: Assume two pkts were received simultaneously, and both used the first 


/* polynomial, R(3,7) to determine their pn sequence. 


The end result is 


f= array of ptrs to packet_list[0] will. point to a linked list, and the elements of 


Methis fist will be the pkt pointers of both received pkts, 


size of list = 72s 


/* once all the simultaneous received pkts have been gone through, we merely go 


/* through this array and find the size of each list. 
/* this indicates N pkts were simultaneously received 


/* We destroy them and adjust our counters, 


/* for now, create the lists */ 
mor (ix—O; ix < NUMBER PN CODES; ++1x) 


eaaewor DtLrs to _packet_ vst (ix) =Sepiprgeltstleseat 0, 


Mm set the initial condition of the shift register. 


Seemeegicter to first state(shift_register, 


If the list has N > 1 elements, 
that had the same PN code. 


which we will see. 


REGISTER_BIT LENGTH) ; 


lig 
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for(ix = 0; ix < NUMBER PN CODES; ++1x) 
{ 
Seoepee or -ameemiarst Staec(Shift register, REGISTER BIT LENGTH); 
for (3x eo 7X fe NUMBER _ bigs SEQUENCES; ta 
{ 
generate pn. sequence (matrix_of pn_sequences[ix][Jx].bit array, shift register, am 
get_ next register state(shift_register, REGIS TERIBT SeeNG rae, 


SYNC State 


/* there is only one place for pkts to come from, as this receiver has only ome “Th 
/* channel. the only stream intrpt to expect is from the uplink. Get the packet + 


GeCemueCmpkKpEr = Opepkedet mer Ine mpe si: rni ey, 

ieee eee Ceo colt cee ie Cees ee) and )) 

{ 
/* we need to get the pointer, from the pkt, that is pointing to the memory “7 
/* location of our bits. Recall that our packet only contains one fiom “oy, 
/* SPREADED DATA, and this field is defined as a strucutre. In actuality, fee 
/* a pointer to the memory location of all of our spreaded bits. Only the as 
/* pointer traversed the pipeline, and the bits remained 'safely' inside of i 


/* memory. The total size of the pkt was set in the PN SPREADER process, which */ 
/* allowed the pipeline stages to perform their necessary calculations. Now, we*/ 
/* need to extract this pointer and manipulate the bits. Specifically, i / 
/* correlate the sync bits. Recall as well, that accessing the structure field */ 
/* of this pkt will ‘encapsulate the bits from the pkt. We" Tipnecdmi. 'reset lia 
/* this pointer back into the pkt before we leave this state, as the DECODE *y 
/* state will need it to find and decode the information bits. a 


Seueadedsbles rr — process Ene new Guy (necelved pkprr)) 
if (spreaded_ pees pti |= (short *) OPC NEB} 
{ 
do 
{ 
/* loop through, as necessary, all the PN codes and their variants */ 
Pema Ol; (ix < NUMBER PN CODES) && (Yachteved sync)) a aiean 
fOr(gx-0; 3x < max number of correlations (to Compute a ian, 
/* correlate the two packets nay 
Se wemcorre baktons— 
correlate sync bits(spreaded bits ptr,matrix_of pn _sequences[ix) []x] = Oaseeeeee 


i 


/* if magnitude(syne correlation) >= magnitude(our user defined threshold) */ 
/* we're golden. oy 
Pigrdos\syme Comrelatlon) >= syncwlnmcsnelay 
{ 
JeMteved (Ss /ne -—JOLC TRUE, 
array _ of Jptrs ,tompn . ~ sequences [ix] = 
Matrix of pn sequences [ix] [jx].bit array; 


/* need to maintain this pkt as discussed in the INIT state. *y 
/* tag _and_store this pkt()will attempt to reinsert the 7 
/* the spreaded bits ptr into the pkt, and if successful, will a 
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/* attempt to place this pkt in the list being pointed to by the a 


/* pointer element, array of ptrs tegpacketwlist | ix iid see oa 
/* element is pointing to a list which consists of a pointers to me 
/* pn sequences which match the pn sequence that the respective a 
/* pkt was able to synchronize on, such as this one. If syne has ay | 
/* been achieved, then the pn sequence with which it was synchronized */ 
/* "on 1S LouRdeineenessD mMatri, x / 


/* matrix of pn Sequences /ix] [jx] .bit array. bitederayeioed Ceted] ame 
/* structure of short(].ix was assigned to peimt to (enews eeace 1c uo 
/* sequence in the above assignment. we now want to store this pointer*/ 
/* for safekeeping. * / 


safe keeping = tag_and_ store this _pkt (received pkptr, 
spreaded bits ptr,array of ptrs to packer listlax), 


/* if we somehow managed to sync on a pkt, but couldn't restore a 
/* the dataibits pointer into the pkt, we've lestecun @dataemwe our a 
J? “ChoCckheeiseoneaup, co RuntS. * / 


if(!safe keeping) 
update stats(RUNT PACKET, ADD ONE); 


/* we've achieved sync on this pkt, so let's bail out of this loop */ 
break; 
ine, ema of+ if (tabs(syne correlation) —— syne senresholauuac, 
le = 6nd ofy for jx < upper bound */ 
Mmeeeend Of; for ix < NUMBER PN CODES) && (!achieved Syne) 9 *7 


/* we've now been through all the polynomials defined in code matrix[][]. If */ 
/* we haven't been able to sync yet, we're hosed, as we have checked all ah 
/* possible pn sequences and all phases (dependent on long correlation) ni, 


eomueri! codes checked = OPC TRUE; 
Meee, ! (achieved sync || all PN codes checked) ),; 


PieiemLevyed Sync) 
Gp intrpt schedule self(op_sim_time({) + TAU, SYNC_ACHIEVED); 
/* need a time delay, see INIT comments */ 


else j= this pkt is hopeless junked bits. we" lle desircy 2: anc. 
/* release the memory x | 
{ 
/* increment our counters, deallocate used memory, and destroy the trashed pkt.*/ 
Update stats (SYNC FAILURES, ADD ONE); 
ieekeat stats of pkt(received pkptr); 
ee-an up the mess (received pkptr, Sprcadedee Heouern 
} /* end else */ 
feed of: if(spreaded bits ptr != (short ~} OPG NIL) 7 
Mee emo or: if(received pkptr != (Packet *) OPC NTE) =] 


else /* the pkt is somehow a NIL pkt, can't do anything with it. */ 
op sim_message("DESPREADING PROCESS: SYNC STATE: PKT FROM STREAM IS NIL?", "No Clue."); 
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DECODE State 


/* we're here only because we were able to achieve synchronization on the ye 
/* received spreaded packet in the SYNC state. If sync was achieved, the received */ 
/* pkt was placed inside a list (acutally an an array of list pointers). As the by 
/* SYNC state will be invoked for each received pkt at time = END RX, we need to ba 
/* to maintain all pkts that passed synchronization until all received pkts have i 
/* have been processed. Once OPNET has processed all the events in the event list +4 
oa edo ork INTRET's), we can then safely /* move to this DECODE state sama ba: 
/* attempt to decode the data of the received pkt. We now have an array of list a 
/* pointers, each pointing to a list of pkts which were synchronized with the same */ 
/* PN code sequence (if any). If there are more than one pkt in each list, we have */ 
/* a collision caused by multiple PN code sequences. * / 
/* now that we are here, we'll need to correlate the mac and data pkt and extract * 
ay 

/* the information.We know from the correlation process of the synchronization bits */ 
/* what particular characteristic polynomial and what initial register load was 27, 
/* used by the transmitter. That info has been maintained in our state variables. */ 
/* From that info, we have also already discovered our PN sequence that was used + 
/* to spread the information on the transmitter end. At this point, we have a pkt 7 
/* of spreaded information which has been stripped of the synchronization bits. +7, 
/* Recall our array of ptrs_to_ packet list[] was declared Toghold pointers gaa 7h 


/* list of pkt pointers. We need to loop through the array, check each list pointed */ 
/* to by the array element. If there are more than one elements in each respective */ 
/* list, this indicates we had packets with the same PN sequence. Deal with it. 77 


for(ix=0; ix < NUMBER PN CODES; ix+t) 

{ 
/* Mowemany pkts are in the list pointed to by array of persn..... Js pies a 
number of packets_in list = op_prg_list_size(array of ptrs_ to packet liseli 


/* if there are N > 1 items in the list, we have colliding sequences = colliding pkts. 
on 


/* any colliding packets are considered junk pkts, as we cannot determine from Bae 
/* which user they originated from. This is the cool aspect of CDMA and this 7 
/* slotted ALOHA business, in that-we can have multiple users accessing the "A 


/* network and only those with duplicate PN codes are considered truly collisions.*/ 


init: Me mepaekers an kiste > i) 
{ 
update stats(PN COLLISION, number _of_packets_in_ list); 
empty the list_of junk pkts(array of ptrs_to packet _list/ix], 
numberVor packeesoieiim licen, 


/* else if there is only one element in the list, ok. we received a pkt with = 
/* the corresponding PN sequence polynomial. Get this pkt from the list, = 
joa then: ue 
ee strip the synchronization bits from the pkt. * f 
Le strip the MAC header bits from the pkt a. 
ie correlate what's left = only data and attempt to recover the data a 
fe and don't forget to destroy the original pkt remaining in the list. oo 
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else if (number of packets injiacee a 
{ 


/* if only one pkt in the list, i1t‘s a successful reception =u pdatenc te oe ee 
update stats (GOOD PACKET, ADD ONE); 


/* We're in this branch because there was only one pkt in the linked list, me 
/* which indicates there were no PN Collisions. The pkt currently has a sync */ 
/* header and a mac header prefacing the information data bits, and all of this*/ 
/* has been spreaded by our PN sequence in the transmitter. We recovered this */ 
/* pn sequence in the SYNC state (or we wouldn't be here). What is left to do */ 


/* is to strip the sync bits, strip the mac header bits, then despread Ee 
/* (correlate) the data bits and attempt to recover aS many aS we can. The ay 
/* error.ps.c pipeline stage was our error injector. Based on the determined ay 
/* BER, this error pipeline stage may very well have ruined some of our bits. */ 


/* Recall that our pkt only contains a pointer to the spreaded bits in memory. */ 
/* Rather than actually stripping the sync and mac header bits from the 'pkt' */ 


feewe'll pass this pkt to cur correlate data bits() function which will: are 
a extract the spreaded bits ptr from the pkt, skip past the sync and mac ry: 
a header bits, then correlate the bits from that point on. x7, 
/* The correlated data values will be returned in data _array[]. The memory ty 
/* allocated and pointed to by our memory ptr *spreaded_ bits ptr will be x 
eeecallocated within correlate data bits() 7, 
/* first, get (effectively removing) the pkt from the linked list.we can zy 
/* either access or remove an element in the list. Accessing allows a] 
/* non-destructive querying values of the pkt, whereas removal will actually a7, 
/* remove the item from the list. wow, what a conept huh. ay. 
/* there should only be one packet in the list pointed to by 7 
feeGndy Of Pptrs to packet list[ix] at this point. get a pointer to it. Pay 
eeeaaed data pkptr = (Packet*) op prg list remove(atray of ptrs to packeeiiseii. |. 


OPC_LISTPOS HEAD) ; 
iesoreaded data pkptr != (Packet *) OPC NIL) /* never assume! */ 
{ 
number of data bits = 


correlate data bits(spreaded_ data_pkptr, array of ptrs to pn_sequences[ix], 
data_array, data_threshold); 


/* we should now have an array containing the recovered transmitted data ay 
/* bits (assuming the signal was legit). we'll 'repacketize' these data oy 
pa / 

/* data bits and send them on their merry way. In this case, their merry roy 
/* way is considered to be the next protocol layer, like maybe the MAC a 


/* layer. Our MAC layer consists of a SINK process which will just destroy ay 
/* the pkt. We could do it here as well, but our intent is to complete this */ 
/* entire path from tx to rx. With this approach, we can easily use a module */ 
/* other than SINK for our next process, and minimal recoding is required. */ 
/* This keeps this implementation somewhat cohesive. * 


ye number of data bits tells us how many data bits aves thee ae 
recovered data pkptr = packetize_recovered_data(data_array, number of data bits); 
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Peo eevemeoaucdata pkotr != (Packet *) OPC NIL) 
emp kescma recoveredsdata pkpba,lO HIGHER LAYER); 
Se 
op _sim_message ("ERROR: DESPREADER: DECODE STATE:", 
"Unable to recover data bits. Your data from this packet is losuage 
} 
else; /* else the SYNC state inserted a null pkptr into our 1ist je theweae a 
/* who knows why. now action required, as there is nothing to destroy */ 


ee ene Of melse sit (numoecrroi packet Sein i Ste 0) 
ae eeewcdeot: ix < NUMBEREPNPGODES */ 


/* we have effectively recovered any data pkts that were received collision free. 7, 
/* this includes packets that suffered MAI from other arriving pkts w/different PN a7. 
/* codes likewise, we have destroyed any pkts that were collisions in the sense ee 
/* that they had the same PN sequence. Thisprocess was invoked due to a self ao 
/* interrupt scheduled in the SYNC State. iy 
/* Thus, there are as many interrupts waiting to invoke this process */ 
/* as there were multiple pkts received. We're probably best off by going throughtiesea 
/* event list and removing the remaining events scheduled for this process. All the a7, 
/* necessary work to recover all non-colliding packets and interfered packets has been */ 
/* been done in this first invocation. As well, all colliding packets have been 7 
/* destroyed, counters adjusted, and the linked list(s) pointed to by */ 


/* array of ptrs to packet list[] has been gone through, destoying any packets tiem ie | 
/* were in this list, as they have all been dealt with accordingly. Good housekeeping */ 
/* suggests we clean up our mess. thus, we'll loop through the event list checking for*/ 


/* any remaining INTRPT SELF's. If they are of code SYNC ACHIEVED, then they were ui 
/* scheduled in the SYNC state. There is at least one other INTRPT SELF currepie ey 
/* scheduled, an END SIM interrupt, so don't kill it. The only apparent danger, at ay, 
/* this stage, is that there could have been arriving packets in the next slot time af, 
/* that have been through the SYNC state, and thus have scheduled a INTRPT_ SELF for ae 
/* themselves. a, 
/* However, the interrupt scheduled in the SYNC state is with a nominal time delay, wh 
/* call it tau, after completing the SYNC state. as long as tau < guard time, i 


/* we should be safe. As a complete check, we can check the approximate scheduled time */ 
/* of the events, and cancel only those that are scheduled for about this time, which */ 
/* would be those remaining interrupts scheduled in this slot time. *7 


/* now I'm thoroughly confused. maybe the code will be clear. . gr 


Clean up event list(); 
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